home *** CD-ROM | disk | FTP | other *** search
/ Magnum One / Magnum One (Mid-American Digital) (Disc Manufacturing).iso / d12 / c_conf2.arc / C2 next >
Text File  |  1990-07-10  |  871KB  |  19,882 lines
  1. 2dwk1312
  2.  
  3. P to pause, S to cancel output
  4. ------------------------------
  5.  
  6. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DWK1312 Date: 09/27/89
  7. From: STEVEN SCHULZ                                         Time: 04:21 pm
  8.   To: ALL                                                   (Read 103 times)
  9. Subj: MEMORY AVAILABLE
  10.  
  11. I'm using Microsoft "C" 5.1 and was wondering if there is a way to check
  12. how much memory is available.  I would like to use this from within my
  13. program after I have already done a series of malloc()'s.  I'm only
  14. interested in conventional memory, but it has to be all the available
  15. free memory not just the memory available in the default data segment.
  16. ---------------
  17. Following thread
  18.  
  19. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DWL3457 Date: 09/27/89
  20. From: GRANT ELLSWORTH (Leader)                              Time: 05:57 pm
  21.   To: STEVEN SCHULZ (Rcvd)                                  (Read 101 times)
  22. Subj: R: MEMORY AVAILABLE
  23.  
  24. There should be a "memavail()" type of function in your C library.  I
  25. don't remember the MSC function name right now, but I do remember being
  26. able to use a function name directly when I did a port from TC 1.5 to
  27. MSC5.x several months ago.  Grant
  28. ---------------
  29. ** Current thread: MEMORY AVAILABLE
  30.  
  31. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DWM2166 Date: 09/27/89
  32. From: JOE VINCENT                                           Time: 06:36 pm
  33.   To: GRANT ELLSWORTH (Rcvd)                                (Read 101 times)
  34. Subj: R: MEMORY AVAILABLE
  35.  
  36. Message CC'd to:
  37.      GRANT ELLSWORTH
  38.      STEVEN SCHULZ
  39.  
  40. >There should be a "memavail()" type of function in your C library.  I
  41. >don't remember the MSC function name right now, but I do remember being
  42.  
  43. Grant, you're thinking of the "_memavl" function, but that one only
  44. returns the memory available in the default data segment and Steve wanted
  45. total memory available.  The only thing I can think of right off hand is a
  46. kludge: determine the total memory USED and subtract that from the total
  47. memory in the machine, obtained using the "_bios_memsize" function.
  48.  
  49.      -=≡{JOE}≡=- (tm)
  50. ---------------
  51. ** Current thread: MEMORY AVAILABLE
  52.  
  53. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DXC2085 Date: 09/28/89
  54. From: STEVEN SCHULZ                                         Time: 08:34 am
  55.   To: GRANT ELLSWORTH (Rcvd)                                (Read 97 times)
  56. Subj: R: MEMORY AVAILABLE
  57.  
  58. There is a _memavl() function in MSC's library but it only checks the
  59. memory available in the default data segment, not across all segments,
  60. which is what I really need.  I don't think there are any functions
  61. supplied that do this, unless I'm missing something??
  62. ---------------
  63. ** Current thread: MEMORY AVAILABLE
  64.  
  65. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DXC2459 Date: 09/28/89
  66. From: STEVEN SCHULZ                                         Time: 08:40 am
  67.   To: JOE VINCENT (Rcvd)                                    (Read 102 times)
  68. Subj: R: MEMORY AVAILABLE
  69.  
  70. Joe, I also seem to remember reading somewhere about a routine to do what
  71. I need.  Basically you call malloc() and ask for say 10,000 bytes.  If
  72. NULL is not returned, do it again.  If NULL was returned, reduce the
  73. memory block asked for in half and try again.  This process would continue
  74. until no more memory could be malloced.
  75.  
  76. I'm going to do some digging to see if I can find the algorithm, otherwise
  77. I'll try writing my own.  Maybe Turbo C has a function to check on all
  78. available free memory, as Grant seems to think.  Thanks.
  79. ---------------
  80. ** Current thread: MEMORY AVAILABLE
  81.  
  82. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DXN0223 Date: 09/28/89
  83. From: JOE VINCENT                                           Time: 07:03 pm
  84.   To: STEVEN SCHULZ (Rcvd)                                  (Read 94 times)
  85. Subj: R: MEMORY AVAILABLE
  86.  
  87. >Joe, I also seem to remember reading somewhere about a routine to do what
  88. >I need.  Basically you call malloc() and ask for say 10,000 bytes.  If
  89. >NULL is not returned, do it again.  If NULL was returned, reduce the
  90. >memory block asked for in half and try again.  This process would continue
  91. >until no more memory could be malloced.
  92.  
  93. Steve, doesn't "malloc" work against the heap rather than all memory?  In
  94. any event, although the technique might be made to work in some form, it
  95. sure seems inelegant.
  96.  
  97.      -=≡{JOE}≡=- (tm)
  98. ---------------
  99. ** Current thread: MEMORY AVAILABLE
  100.  
  101. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DXQ2775 Date: 09/28/89
  102. From: GRANT ELLSWORTH (Leader)                              Time: 09:46 pm
  103.   To: JOE VINCENT (Rcvd)                                    (Read 93 times)
  104. Subj: R: MEMORY AVAILABLE
  105.  
  106. Joe, As I recollect it, the _memavl() function returns the memory
  107. remaining in the "heap".  I think there is also some function which will
  108. return the memory available in the "far heap".  In TC2.0, these functions
  109. are "coreleft()" and "farcoreleft()" respectively.  In that somewhat
  110. ancient port I did from TC2.0 to TC5.0 (or was it TC1.5 to MSC5.0???,
  111. can't remember), I had to cover for both functions.  I don't have the MSC
  112. references around any more.  Maybe somebody else has a handle on this.
  113. ... Grant
  114. ---------------
  115. ** Current thread: MEMORY AVAILABLE
  116.  
  117. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DXQ3335 Date: 09/28/89
  118. From: GRANT ELLSWORTH (Leader)                              Time: 09:55 pm
  119.   To: STEVEN SCHULZ (Rcvd)                                  (Read 97 times)
  120. Subj: R: MEMORY AVAILABLE
  121.  
  122. Now that you mention the wriggling around with the malloc(), i think the
  123. calloc() function is what can be used to achieve the same results a little
  124. more easily.  Also, there is in MSC5.0 something like a "freect()"
  125. function which tells you how many times you can call malloc() with a
  126. certain size specification.  DON'T try getting the count using a size spec
  127. of 1!!!!!!! There is an 8 or 16 byte overhead coming out of the total
  128. memory available for each separate malloc()'ed area!  Thus this darn
  129. function is a tad deceiving.  Hope this helps.   I think you'll note in a
  130. msg I just left Joe Vincent that TC has the functions you need.  Grant
  131. ---------------
  132. ** Current thread: MEMORY AVAILABLE
  133.  
  134. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DYS1331 Date: 09/29/89
  135. From: GLEN THOMPSON                                         Time: 11:22 pm
  136.   To: STEVEN SCHULZ (Rcvd)                                  (Read 95 times)
  137. Subj: R: MEMORY AVAILABLE
  138.  
  139. Steven,
  140.  
  141. Turbo-C has a function called farcoreleft() that returns a long int of the
  142. memory available on the system.  Works well since I was just using it
  143. yerterday in a program to make sure enough memory was available before
  144. executing another program.
  145.  
  146. I don't think MSC has an equivalent function.
  147.  
  148. glen
  149. ---------------
  150. ** Current thread: MEMORY AVAILABLE
  151.  
  152. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DZN3059 Date: 09/30/89
  153. From: TOM FRANK                                             Time: 07:51 pm
  154.   To: GLEN THOMPSON (Rcvd)                                  (Read 93 times)
  155. Subj: R: MEMORY AVAILABLE
  156.  
  157. Glen,
  158.  
  159. There is a way in MSC to find out how much memory is left - although a bit
  160. of a kludge.  A call to _dos_allocmem asking for more memory than is
  161. possible will return an error and give you the number of paragraphs of
  162. memory available - see the RTL docs on this function (for MSC 5.1 only).
  163.  
  164. BTW - it just calls the DOS memory alloc function so you could always use
  165. the INT86 functions to access it directly.
  166.  
  167. Tom
  168. ---------------
  169. ** Current thread: MEMORY AVAILABLE
  170.  
  171. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2E2C0543 Date: 10/02/89
  172. From: STEVEN SCHULZ                                         Time: 08:09 am
  173.   To: JOE VINCENT (Rcvd)                                    (Read 101 times)
  174. Subj: R: MEMORY AVAILABLE
  175.  
  176. When using malloc() with the compact and large memory models, malloc is
  177. mapped to _fmalloc, which allocates memory outside the default data
  178. segment.  If sufficient memory is not available, _fmalloc will try within
  179. the default data segment.  If it fails here, NULL is returned.
  180.  
  181. Yes, this solution of repeatedly trying malloc to get the available memory
  182. does sound inelegant.  Also, when memory is malloced I believe a header is
  183. also allocated.  This header would not count in the available memory, so
  184. this solution will probably not be 100% accurate.
  185. ---------------
  186. ** Current thread: MEMORY AVAILABLE
  187.  
  188. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2E2C0885 Date: 10/02/89
  189. From: STEVEN SCHULZ                                         Time: 08:14 am
  190.   To: GRANT ELLSWORTH (Rcvd)                                (Read 100 times)
  191. Subj: R: MEMORY AVAILABLE
  192.  
  193. I will definitely try the _freect() function.  Looks like it will do what
  194. I need.  Must have overlooked it.  Thanks!
  195. ---------------
  196. ** Current thread: MEMORY AVAILABLE
  197.  
  198. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2E2C1092 Date: 10/02/89
  199. From: STEVEN SCHULZ                                         Time: 08:18 am
  200.   To: GLEN THOMPSON (Rcvd)                                  (Read 105 times)
  201. Subj: R: MEMORY AVAILABLE
  202.  
  203. You are right, MSC does not have a similiar function to the farcoreleft()
  204. that TC does.  I'm going to try using _freect(), which returns the
  205. approximate number of times malloc() can be called to allocate a given
  206. size data item.  In my case I will use a char to find out how many bytes
  207. are available.
  208. ---------------
  209. ** Current thread: MEMORY AVAILABLE
  210.  
  211. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2E2L2002 Date: 10/02/89
  212. From: GRANT ELLSWORTH (Leader)                              Time: 05:33 pm
  213.   To: STEVEN SCHULZ (Rcvd)                                  (Read 109 times)
  214. Subj: R: MEMORY AVAILABLE
  215.  
  216. Steven, before you go leaping into _freect() to determine the ram
  217. available by using a single byte as the size of element, consider the
  218. OVERHEAD needed to support each malloc() unit.  I suggest that you try
  219. some size larger than a paragraph (16 bytes) to get a more accurate count.
  220. It has been my experience that each malloc() allocates the memory for each
  221. new unit to be on a "quadword (8-byte)" boundary ... and then there is the
  222. DOS overhead (8-bytes?).  Grant
  223. ---------------
  224. ** Current thread: MEMORY AVAILABLE
  225.  
  226. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2E2P3071 Date: 10/02/89
  227. From: DAVID THOMAS                                          Time: 08:51 pm
  228.   To: STEVEN SCHULZ (Rcvd)                                  (Read 110 times)
  229. Subj: R: MEMORY AVAILABLE
  230.  
  231. Steven:
  232.  
  233. Since you are running under some varient of DOS, why not skip all
  234. the malloc()  overhead and repeated calls, etc. and simply use DOS int 21,
  235. functions 48h and 49h?  48h allocates a memory block of a requested size,
  236. and on failure returns the size of the largest available memory block.
  237. Function 49h is the reciprocal of 48h, releasing previously allocated
  238. memory.  I believe both MSC and TC have a "regs" struct predefined for use
  239. with a dosint() or int86() type of call.  If portability is an issue, put
  240. a front end on the function calls to allow a rewrite under another
  241. architecture.  Functions 48h and 49h are the tools your C library uses to
  242. implement malloc() and company anyway, so why live with the overhead?
  243.  
  244. Good luck any road...
  245.  
  246. David
  247. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  248.  
  249. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DWL3286 Date: 09/27/89
  250. From: GRANT ELLSWORTH (Leader)                              Time: 05:54 pm
  251.   To: JOHN LLOYD (Rcvd)                                     (Read 95 times)
  252. Subj: R: B-TO-C
  253.  
  254. It's possible that I saw those other BASIC-TO-C translator(s) on another
  255. BBS ... and recalling that I saw them at all was an archeaological exped-
  256. ition.  I suggest you try accessing "THE TOOL SHOP" in Phoenix, AZ
  257. (accisible via PCPURSUIT) at 602-279-2673.  The Tool SHop also has a
  258. commendable upload set --- not as elaborate or deep as the one here on
  259. EXECPC, of course, but it has a different focus (C and pgming tools).  Be
  260. prepared to wait a LONG WAIT on redials to get connected - that bbs is
  261. real popular out in that part of the West.  Grant
  262. B
  263.  
  264.  
  265.  
  266. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DWK1312 Date: 09/27/89
  267. From: STEVEN SCHULZ                                         Time: 04:21 pm
  268.   To: ALL                                                   (Read 104 times)
  269. Subj: MEMORY AVAILABLE
  270.  
  271. I'm using Microsoft "C" 5.1 and was wondering if there is a way to check
  272. how much memory is available.  I would like to use this from within my
  273. program after I have already done a series of malloc()'s.  I'm only
  274. interested in conventional memory, but it has to be all the available
  275. free memory not just the memory available in the default data segment.
  276. ---------------
  277.  
  278. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DWJ3303 Date: 09/27/89
  279. From: KEN HOPKINSON                                         Time: 03:55 pm
  280.   To: JODY IRISH (Rcvd)                                     (Read 97 times)
  281. Subj: R: TURBO-C CRUIT
  282.  
  283. Hi Jody,
  284.      One program you might want to look at for learning C is CROBOT in the
  285. mahoney collection. It isn't really that complicated when you look at what
  286. you can use, but its kind of fun to see how close you can make your robot
  287. into a thinking machine that'll wipe everyone else out.
  288.  
  289. ken
  290. ---------------
  291.  
  292. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DW52154 Date: 09/27/89
  293. From: JOHN LLOYD                                            Time: 05:35 am
  294.   To: GRANT ELLSWORTH (Rcvd)                                (Read 97 times)
  295. Subj: R: B-TO-C
  296.  
  297. Thanks, I will look for the ones mentioned.  Already did the search,
  298. without results cept for b-to-c.
  299. ---------------
  300.  
  301. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DVR3589 Date: 09/26/89
  302. From: JODY IRISH                                            Time: 10:59 pm
  303.   To: ALL                                                   (Read 92 times)
  304. Subj: PASSWORD.C
  305.  
  306. Hello everybody,
  307.     You may have already written a better program, but I'm kinda proud of
  308. this small program, as it's the first one I actually thought of and wrote.
  309. After many failures and re-tries, I got something to work!!!
  310.  
  311.      The file is called PASSWRD.ZIP.  It should be somewhere in Bob's
  312. collection under programming support or language support???  It was
  313. written on turbo-c 1.5, but should be easy to convert.  The .EXE file
  314. should be about 9K or so, it's not resident, and I access it in my
  315. autoexec.bat on the hard drive.  It's free to all... please don't sell it,
  316. just pass it around and don't lay claim to it!
  317.  
  318.      There is a readme file included in the zip-file to explain further,
  319. and comments in the source.
  320.  
  321. From: Jody L. Irish, I.M. Computing
  322. ---------------
  323.  
  324. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DVR2726 Date: 09/26/89
  325. From: JODY IRISH                                            Time: 10:45 pm
  326.   To: GRANT ELLSWORTH (Rcvd)                                (Read 93 times)
  327. Subj: R: TURBO-C CRUIT
  328.  
  329. Grant,
  330.        Thanks for a welcome!  I am not a programmer by trade, just
  331. curiosity.  I learned BASIC waaaaaayyyyyy back in high school, then
  332. fortran, but forgot most all of it.  Tried to self-teach myself Turbo
  333. Pascal, but really found myself hosed up with structured programming.
  334. I didn't understand the concept, but upon reading about Turbo-C while
  335. watching a self-taught peer of mine (and kinda mentor/tutor), I started
  336. figuring it out.  What I found most helpful was pull-down menus and being
  337. able to read the include files, once I learned what they actually were!
  338.  
  339. I am going to upload a small password program tonite (soon).  It's one of
  340. my first lessons in curiosity-killed-the-cat!  At first, it re-wrote the
  341. boot track of drive c: to the near last track (605 on my st-225), then if
  342. the correct password given, wrote it back to finish the boot... BUT...
  343. After performing several lowlevel formats, I scrapped that idea: TOOOOO
  344. DANGEROUS!!!  So it just leaves you with a red screen.  I am leaving only
  345. the source code for all to use, free material.  Will this create any
  346. hassles?  I hope no greedy people try to profit!  I figure it's worth
  347. about $.25 myself!!!
  348.  
  349. Again, thanks for welcoming me, am very interested in C and sharing
  350. experiences and problems.
  351. From: Jody L. Irish, I.M. Computing
  352. ---------------
  353.  
  354. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DVQ2172 Date: 09/26/89
  355. From: JOHN HEIM                                             Time: 09:36 pm
  356.   To: MICHAEL KUMBERA (Rcvd)                                (Read 98 times)
  357. Subj: R: NEURAL NET'S
  358.  
  359. Michael,
  360.  
  361. It's really been bugging me that I couldn't find your BIX stuff.  I'm
  362. going to poke around again when I get the time.  If you have success
  363. through other means let me know.  I was thinking that they might remove
  364. code listings after a certain period of time.
  365.  
  366. John
  367. ---------------
  368.  
  369. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DVQ1861 Date: 09/26/89
  370. From: GRANT ELLSWORTH (Leader)                              Time: 09:31 pm
  371.   To: JOHN LLOYD (Rcvd)                                     (Read 96 times)
  372. Subj: R: B-TO-C
  373.  
  374. I remember seeing something named BAS2C.xxx or BASTOC.xxx in the mahoney
  375. collection some many moons ago.  Check these out.  Also, you might try the
  376. hypertext scan to look for "BAS" and " C ".  Grant
  377. ---------------
  378.  
  379. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DVQ1696 Date: 09/26/89
  380. From: GRANT ELLSWORTH (Leader)                              Time: 09:28 pm
  381.   To: JODY IRISH (Rcvd)                                     (Read 94 times)
  382. Subj: R: TURBO-C CRUIT
  383.  
  384. Jody, Like a lot of others here in this topic/conference, I taught myself
  385. C using Turbo C (and a couple of other compilers a little later).  Maybe
  386. you should begin by stating what base you were starting from - e.g.:
  387.  
  388. 1.  Previous work with which programming tools/languages
  389. 2.  How long and doing what kind of hobby or pro-programming
  390.  
  391. Also, you might want to tell us what you are finding the most confounding
  392. in learning/using C, Turbo C, etc..
  393.  
  394. Somewhere back in Feb/Mar., we had a short discussion going on here about
  395. the problems of learing C - as a 2nd (or 3rd, etc.) programming language
  396. vs as the very first programming language.  The consensus seemed to be
  397. that learning C as the very first programming language was an invitation
  398. to frustration city.  Some even thought that prior exposure to, if not
  399. extensive work with, some other compiled block-structured language like
  400. PASCAL or PL/I (for IBM 370 Mainframers) was highly desirable, if not
  401. necessary.  One person wrote that he learned C only after some work with
  402. dBASE III(?) and found it a very frustrating journey --- but he wrote that
  403. he finally got the hang of it.
  404.  
  405. For my part, my programming "mother toungue" is mainframe assembler and C
  406. was the 1st so-called "Higher Order Language" I took seriously.  However I
  407. did have some prior exposure to PASCAL and its ancestor, ALGOL 60 -- a
  408. long time before.    grant
  409. ---------------
  410.  
  411. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DV51941 Date: 09/26/89
  412. From: JOHN LLOYD                                            Time: 05:32 am
  413.   To: ALL                                                   (Read 95 times)
  414. Subj: B-TO-C
  415.  
  416. Well, I didn't luck out on the B-TO-C.  Does anyone know of a shareware or
  417. public domain program that with convert, even loosly, a GWBASIC program to
  418. C source.  A friend is trying to learn C and feels that if he could write
  419. a small basic program, convert it and study the resultant source code, it
  420. would help him to understand C more easily.
  421. ---------------
  422.  
  423. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DUP1048 Date: 09/25/89
  424. From: JODY IRISH                                            Time: 08:17 pm
  425.   To: ALL                                                   (Read 95 times)
  426. Subj: TURBO-C CRUIT
  427.  
  428. Hello,
  429.       I have trying to teach myself Turbo-C for the last year or so...
  430. Would enjoy experiences and converse of others who tried the same.  I
  431. currently use ver 1.5 and am known for bangin' my forehead on objects,
  432. from styrofoam insulated walls to concrete blocks, have dented fenders,
  433. but not engine blocks!  Am willing to share anything I've learned.
  434. jli
  435. ---------------
  436.  
  437. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DUK1178 Date: 09/25/89
  438. From: ROBERT BALSOVER                                       Time: 04:19 pm
  439.   To: AMERICA WEST (Rcvd)                                   (Read 106 times)
  440. Subj: R: PRO-C
  441.  
  442. Jim, I have been considering PRO-C, I'd like to here opinions about it
  443. and anything anyone else tells you.
  444. Thanks  Bob
  445. ---------------
  446.  
  447. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DSR0425 Date: 09/23/89
  448. From: GRANT ELLSWORTH (Leader)                              Time: 10:07 pm
  449.   To: ERIC WILSON (Rcvd)                                    (Read 99 times)
  450. Subj: R: FUNCTIONS
  451.  
  452. Eric, some of the compilers have built-in library functions for searching
  453. and sorting - e.g. the Turbo C 2.0 compiler has qsort() and bsearch() (a
  454. binary search routine).  Books on sorting and searhing techniques are also
  455. available: Knuth, Donald, Sorting and Searching (Art of Programming Vol 3)
  456. is a classic on the subject.  Also see, The C Toolbox, by William Hunt, or
  457. Algorithms, by Robert Sedgewick.  Some of the "Advanced C" type books I
  458. have seen on the shelves of technical book stores also have some sample
  459. sorting and searching algorithms written in C.  Hope these comments help.
  460.  
  461. Grant
  462. ---------------
  463.  
  464. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DSI2036 Date: 09/23/89
  465. From: ERIC WILSON                                           Time: 02:33 pm
  466.   To: ALL                                                   (Read 100 times)
  467. Subj: FUNCTIONS
  468.  
  469.  Does anyone know where I can get some type of sorting and searching
  470. functions. If there are no functions written a title to a good book that
  471. discusses this topic would be a great help.
  472.    Thanx in advance !
  473. ---------------
  474.  
  475. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DSB1745 Date: 09/23/89
  476. From: AMERICA WEST                                          Time: 07:29 am
  477.   To: ALL                                                   (Read 108 times)
  478. Subj: PRO-C
  479.  
  480. Has anyone out there had any experience with PRO-C from Vestronix?
  481. We have purchased and are using it to generate C code, we are generating
  482. applications that have data files compatible with dBase III+ so we are
  483. using DBCIII+ routines from Lattice.  The code generator seems to
  484. generate good C code (lots of it!).  I have a lot of experience
  485. programming in Basic and just a rudimentary knowledge of C.  I can usually
  486. determine what a C program is doing by reading the source code, but I am
  487. nowhere near proficient in generating C code.  What have been your
  488. experiences with this package?  Have there been any major problems with
  489. the code that it generates?  Any comments would be greatly appreciated.
  490. Jim Arner
  491. America West C&E, Inc.
  492. 311 Washburn Drive
  493. Rock Springs, WY 82901
  494. 307-382-5663
  495. FAX-382-7323
  496. ---------------
  497.  
  498. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DS52363 Date: 09/23/89
  499. From: JOHN LLOYD                                            Time: 05:39 am
  500.   To: ALL                                                   (Read 96 times)
  501. Subj: B-TO-C
  502.  
  503. A short time ago I downloaded a programs from the Mahoney section called B
  504. B-to-C.ZIP.  It was for a friend trying to learn C.  While it ran on a
  505. "Hello World" program, the code generated did not look like any C I have
  506. seen.  Output seemed to be an intermediate code which needs further
  507. translation.  I am not a programmer, and could not explain what was going
  508. on.  First guess is that the program (B-TO-C) was not a complete utility
  509. by itself, and perhaps files, or librarys were missing.  Anyone know
  510. anything about this file???  How to use it???  Is there more of it???
  511. Thanx
  512. ---------------
  513.  
  514. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DS13355 Date: 09/23/89
  515. From: JAMES MACHADO                                         Time: 12:55 am
  516.   To: OTTO PORTER (Rcvd)                                    (Read 102 times)
  517. Subj: R: PROBLEMS RUNNING QUICK-C
  518.  
  519. i have 1.00 and 2, i only had the problem with 2, i ended up changing my
  520. dos from an old generic to dri's e've heard of stranger things, but not
  521. many. thanks
  522.  james
  523. ---------------
  524.  
  525. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DRP1898 Date: 09/22/89
  526. From: RICHARD POELING                                       Time: 08:31 pm
  527.   To: JIM MONROE (Rcvd)                                     (Read 98 times)
  528. Subj: R: #1)POWER C  #2)WORD PROCESSING
  529.  
  530. After testing some things on my system, I have concluded that my programs
  531. run fine when I compile them with Power C.  The source of all my problems
  532. seems to be the Utilities that I bought from Mix.  I don't know if it is a
  533. problem with my computer not liking the way their stuff was compiled or
  534. what exactly, but eventually I find it.
  535. ---------------
  536.  
  537. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DQL1636 Date: 09/21/89
  538. From: JIM FISCHER                                           Time: 05:27 pm
  539.   To: PAUL MCKENZIE (Rcvd)                                  (Read 101 times)
  540. Subj: REPORT WRITING
  541.  
  542.  Paul, much thanks and salutations to you! I'll D/L the file and check it
  543. out tonight. Really appreciate your help, I owe you one.
  544.  
  545. Best regards, Jim
  546. ---------------
  547.  
  548. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DQ22927 Date: 09/21/89
  549. From: PAUL MCKENZIE                                         Time: 02:48 am
  550.   To: JIM FISCHER (Rcvd)                                    (Read 94 times)
  551. Subj: R: REPORT WRITING
  552.  
  553. Jim, I have uploaded COMMAFMT.ZIP on the Mahoney Collection.  This should
  554. take care of your problem.
  555.                                  Paul
  556. ---------------
  557.  
  558. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DPS3196 Date: 09/20/89
  559. From: ERIK DUFEK                                            Time: 11:53 pm
  560.   To: JIM MONROE (Rcvd)                                     (Read 95 times)
  561. Subj: R: #1)POWER C  #2)WORD PROCESSING
  562.  
  563. In any type of C discussion, I expect I'll be the slow guy.
  564. ---------------
  565.  
  566. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DPN1096 Date: 09/20/89
  567. From: JIM FISCHER                                           Time: 07:18 pm
  568.   To: PAUL MCKENZIE (Rcvd)                                  (Read 99 times)
  569. Subj: REPORT WRITING
  570.  
  571.  Thanks much for your help, we'll give it a try and let you know the
  572. results.
  573.  
  574. Thanks again, Jim
  575. ---------------
  576.  
  577. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DPD2900 Date: 09/20/89
  578. From: JIM MONROE                                            Time: 09:48 am
  579.   To: ERIK DUFEK (Rcvd)                                     (Read 101 times)
  580. Subj: R: #1)POWER C  #2)WORD PROCESSING
  581.  
  582. I think that both a discussion group here on the BBS as well as some
  583. degree of personnel interaction may be valuable. Lets try it later in the
  584. fall.
  585. ---------------
  586.  
  587. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DP11456 Date: 09/20/89
  588. From: PAUL MCKENZIE                                         Time: 12:24 am
  589.   To: PAUL MCKENZIE (Rcvd)                                  (Read 98 times)
  590. Subj: R: REPORT WRITING
  591.  
  592. Oops, Got the prototype confused.  The call is as follows:
  593. char *comma_fmt(char *buf1, char *buf2)
  594. where buf1 is a pointer to a string representing the number to be
  595. formatted, and buf2 is a pointer to the buffer where the formatted number
  596. is to reside.  The routine requires you to convert the original number to
  597. a string yourself.  You can use sprintf() or your own number to string
  598. routine.  Here is an example:
  599.      int num = 23456;
  600.      char buf2[10]
  601.      char temp[7];
  602.      sprintf(temp,"%d",num);
  603.      comma_fmt(temp,buf2);
  604.      fprintf(stdprn,"%s",buf2);
  605.                                         Paul McKenzie
  606. ---------------
  607.  
  608. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DNS3163 Date: 09/19/89
  609. From: PAUL MCKENZIE                                         Time: 11:52 pm
  610.   To: JIM FISCHER (Rcvd)                                    (Read 93 times)
  611. Subj: R: REPORT WRITING
  612.  
  613. Jim, I have a function that returns a comma formatted number.  It works
  614. with either negative or positive values.  I have the code at my place of
  615. work, so I cannot get my hands on it until tomorrow (Wednesday).
  616. The ANSI prototype to the routine is as follows:
  617.     char *comma_fmt(double num, char *buf)
  618. where num is the number to format, and buf is a pointer to the buffer that
  619. will store the formatted number.  The routine also returns the pointer to
  620. the buffer.
  621.                                  Paul  McKenzie
  622. ---------------
  623.  
  624. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DNR3544 Date: 09/19/89
  625. From: ERIK DUFEK                                            Time: 10:59 pm
  626.   To: JIM MONROE (Rcvd)                                     (Read 94 times)
  627. Subj: R: #1)POWER C  #2)WORD PROCESSING
  628.  
  629. >Is it possible to
  630. >get a mix group together on this board?
  631.  
  632. Bob is waiting for the move before he does any more work in modifying the
  633. topic areas.  But I think the C area is an appropriate area.  C is meant
  634. to be portable so any discussion should usually be relevant with any
  635. compiler.
  636.  
  637. I'm not a serious user of the program yet.  I've used it a few times, but
  638. nothing complicated.  I've downloaded a few of the C tutors though in
  639. anticipation of more serious use in the future.
  640. ---------------
  641.  
  642. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DNR0939 Date: 09/19/89
  643. From: ROBERT BALSOVER                                       Time: 10:15 pm
  644.   To: GRANT ELLSWORTH (Rcvd)                                (Read 97 times)
  645. Subj: R: CALLABLE EDITOR IN C
  646.  
  647. Grant,
  648. Unfortunately I don't have a Pascal compiler, I never saw a need for it.
  649. With all of the good Pascal source out there I would certainly be
  650. willing to pay for a fully functioning translator, but I guess there
  651. isn't enough people like me out there or there would be a package
  652. available.  I can program in Pascal, so I could do it manually but
  653. it takes too long even with a half functioning translator.
  654. Bob
  655. ---------------
  656.  
  657. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DNR0139 Date: 09/19/89
  658. From: MICHAEL KUMBERA                                       Time: 10:02 pm
  659.   To: JOHN HEIM (Rcvd)                                      (Read 98 times)
  660. Subj: R: NEURAL NET'S
  661.  
  662. John,
  663.  
  664. The reason I think it's there is that the BYTE article states that the
  665. program can be downloaded from BIX. I would like to thank you for looking
  666. though.
  667.  
  668.  
  669. Michael Kumbera
  670. ---------------
  671.  
  672. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DNQ1620 Date: 09/19/89
  673. From: JIM MONROE                                            Time: 09:27 pm
  674.   To: ERIK DUFEK (Rcvd)                                     (Read 96 times)
  675. Subj: R: #1)POWER C  #2)WORD PROCESSING
  676.  
  677. I also have the powerc c compiler and have no problem. Is it possible to
  678. get a mix group together on this board?
  679. ---------------
  680.  
  681. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DNQ1473 Date: 09/19/89
  682. From: JIM MONROE                                            Time: 09:24 pm
  683.   To: RICHARD POELING (Rcvd)                                (Read 96 times)
  684. Subj: R: #1)POWER C  #2)WORD PROCESSING
  685.  
  686. I ALSO HAVE THE POWERC C PACKAGE FROM MIX.  I have not had any problems
  687. with the programs. If possible can you upload one tof these to me and I
  688. will try it here to see if the same problem exsists.
  689. Jim
  690. //
  691. s
  692. ---------------
  693.  
  694. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DNQ0696 Date: 09/19/89
  695. From: JIM FISCHER                                           Time: 09:11 pm
  696.   To: ALL                                                   (Read 95 times)
  697. Subj: REPORT WRITING
  698.  
  699. Can anybody give me some advice as to editing data used to print a report
  700. written in 'C'.  I need to know how to edit a numeric field whose length
  701. can be from 0 to 999,999,999. I need to know how to insert the commas
  702. between the numbers if the field is long enough to require them.  This
  703. report is to be printed not displayed on screen.
  704.                                        Thanks,
  705.                                            Jim
  706. ---------------
  707.  
  708. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DNP1616 Date: 09/19/89
  709. From: JOHN HEIM                                             Time: 08:26 pm
  710.   To: RICHARD POELING (Rcvd)                                (Read 95 times)
  711. Subj: R: C & ASSEMBLY LANGUAGE BBS'S
  712.  
  713. Rick,
  714.  
  715. I'm sure CompuServe has conferences on both C and Assembly.  It'll cost you
  716. some bucks to use though.  Most of the people I know that spend a lot of
  717. time on CS use a program that logs them on, downloads the messages they're
  718. interested in and logs them off automatically.  It's available from
  719. CompuServe.  I don't use CS all that much except to ask Borland's tech
  720. support staff questions so I don't know that much about it.
  721.  
  722. John
  723. ---------------
  724.  
  725. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DNP1072 Date: 09/19/89
  726. From: JOHN HEIM                                             Time: 08:17 pm
  727.   To: MICHAEL KUMBERA (Rcvd)                                (Read 94 times)
  728. Subj: NEURAL NET'S
  729.  
  730. Michael,
  731.  
  732. I got on BIX and looked for the code listings for October 87.  Well, I
  733. couldn't find them.  I found Oct '88 and even Oct '89 but not Oct '87.  I
  734. think they're not there.  Maybe there's someone on this BBS that uses BIX
  735. alot who can say for sure.  I looked around for quite a while before
  736. giving up.  Do you have some reason for believing it was there?
  737.  
  738. John Heim
  739. ---------------
  740.  
  741. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DNM0451 Date: 09/19/89
  742. From: GRANT ELLSWORTH (Leader)                              Time: 06:07 pm
  743.   To: ROBERT BALSOVER (Rcvd)                                (Read 96 times)
  744. Subj: R: CALLABLE EDITOR IN C
  745.  
  746. TP2C is not Sam's commercial version.  I think it is the one put out by
  747. Chien(?) Associates in New Orleans.  I noticed an ad from them last winter
  748. when S's s/w was still called TPC or TP2C as well.  Sam and I had a short
  749. dialogue on his bbs about it ... he knew nothing about Chien or that TP2C.
  750.  
  751. BTW, I think any hang you may get in the May 88 version can be easily
  752. fixed if you also have a Pascal Compiler and the TPTC 17 sources.
  753.  
  754. Also, I note that I have to put my machine in autodial for an average of
  755. 50 mins to get into the Tool Shop ... it certainly is a popular BBS out
  756. there in the southwest.   Grant
  757. ---------------
  758.  
  759. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DNC2830 Date: 09/19/89
  760. From: VICTOR DURA                                           Time: 08:47 am
  761.   To: ROBERT BALSOVER (Rcvd)                                (Read 95 times)
  762. Subj: R: CALLABLE EDITOR IN C
  763.  
  764. Robert
  765. Thanks for the tip. I dl and check it out.
  766. Vic
  767. ---------------
  768.  
  769. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DNC2722 Date: 09/19/89
  770. From: VICTOR DURA                                           Time: 08:45 am
  771.   To: STEVEN KEY (Rcvd)                                     (Read 94 times)
  772. Subj: R: CALLABLE EDITOR IN C
  773.  
  774. Steve, Thanks for the info. I'll check it out...Vic
  775. ---------------
  776.  
  777. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DM13002 Date: 09/18/89
  778. From: ROBERT BALSOVER                                       Time: 12:50 am
  779.   To: GRANT ELLSWORTH (Rcvd)                                (Read 95 times)
  780. Subj: R: CALLABLE EDITOR IN C
  781.  
  782. Grant,
  783. I used what I think was the May '88 version. I can't be sure because I
  784. erased it when it puked several times. I decided it was not advanced
  785. enough for my use.
  786. I have seen a comercial TP2C translator advertised in DDJ June '89.
  787. Pg #9 is Programmers Paradise's ad. It lists with them for $199.
  788. I wonder if that is Sam's work.
  789. Any time I try to call the Tool Shop it is busy.
  790. Bob
  791. ---------------
  792.  
  793. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DKS1246 Date: 09/16/89
  794. From: GRANT ELLSWORTH (Leader)                              Time: 11:20 pm
  795.   To: ROBERT BALSOVER (Rcvd)                                (Read 100 times)
  796. Subj: R: CALLABLE EDITOR IN C
  797.  
  798. Bob, I think tptc17 of may 3(?) 88 was the last shareware version.  The
  799. source to it was also distributed.  That was the version I was referring
  800. to.  No, I did not try it out on Borland's Editor Toolbox, but I did use
  801. it to translate a complex MVS performance measurement tool which I
  802. developed in TP3.0.  THere were some problems because of the complex
  803. structures in code and data.  I do remember that a prior version to
  804. TPTC17(g) of May 88 did "puke" on any complicated pascal program.
  805.  
  806. What version did you use - (date and version id)?
  807.  
  808. BTW, Sam has not totally abandoned the translator.  I understand it was
  809. purchased by a company (purchase had Sam attached to it) and that Sam
  810. is improving it over time with a commercial release as the target.
  811.  
  812. You could check with Sam (call the Tool Shop) and find out what current
  813. plans are.    Grant
  814. ---------------
  815.  
  816. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DKK2078 Date: 09/16/89
  817. From: MICHAEL KUMBERA                                       Time: 04:34 pm
  818.   To: ALL                                                   (Read 95 times)
  819. Subj: C++
  820.  
  821. If any of you get a chance to use C++ do it. It adds some great new
  822. functions to C. I recently got the book "Using C++" by Bruce Eckel
  823. (Osborne McGraw-Hill) and it gives a good explination on how to use C++.
  824. Their discussion of using OBJECTS is well done but they could explain
  825. function overloading better. C++ seems like the best programming language
  826. since C.
  827.  
  828.  
  829. Michael Kumbera
  830. ---------------
  831.  
  832. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DKK1262 Date: 09/16/89
  833. From: MICHAEL KUMBERA                                       Time: 04:21 pm
  834.   To: JOHN HEIM (Rcvd)                                      (Read 94 times)
  835. Subj: R: NEURAL NET'S
  836.  
  837. Thanks for the reply John.
  838.  
  839. I found some information that might help you locate the file.
  840. The Issue was Oct. 87 and the program name is bpsim.c also the artical
  841. name is "Back-Propagation, A Generalized delta learning rule".
  842.  
  843.  
  844. Thanks for taking the time to look for the file.
  845.  
  846. Michael Kumbera
  847. ---------------
  848.  
  849. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DK41916 Date: 09/16/89
  850. From: ROBERT BALSOVER                                       Time: 04:31 am
  851.   To: VICTOR DURA (Rcvd)                                    (Read 97 times)
  852. Subj: R: CALLABLE EDITOR IN C
  853.  
  854. Victor,
  855. There is a file in the collection called TURBBOOK.ZIP.  It contains the
  856. source from Al stevens Book Turbo C screen O/I (etc. something like
  857. that)  I have that book and in it he wrote a routine that is exactly
  858. what you asked for.  The source is for TSR's, Windows etc.  The file
  859. would have the correct book name if you want to pick it up.  I've
  860. seen it lately on the bookshelfs so you shouldn't have problems finding
  861. it.  I do recommend the book but it is written for TC 1.0 so you
  862. have to make adjustments if you wish to do TSR's with a later version
  863. of TC.  It otherwise needs no further corrections.
  864. Bob
  865. ---------------
  866.  
  867. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DK40892 Date: 09/16/89
  868. From: ROBERT BALSOVER                                       Time: 04:14 am
  869.   To: GRANT ELLSWORTH (Rcvd)                                (Read 97 times)
  870. Subj: R: CALLABLE EDITOR IN C
  871.  
  872. Grant,
  873. I dunno.  I only used Sam's program, I never looked at any others.
  874. I was attempting to translate the TPascal Editor toolbox and it puked.
  875. Did he continue developement of his program or shelf it?
  876. Bob
  877. ---------------
  878.  
  879. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DK10817 Date: 09/16/89
  880. From: RICHARD POELING                                       Time: 12:13 am
  881.   To: ALL                                                   (Read 98 times)
  882. Subj: C & ASSEMBLY LANGUAGE BBS'S
  883.  
  884. I am interested in locating other BBS's that have a good 'C' programming
  885. conference section.  I would also like to find one that deals with
  886. Assembly language in the MSDOS environment.  Does anyone know of any?
  887. Thanks.
  888. Rick.
  889. ---------------
  890.  
  891. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DJS2501 Date: 09/15/89
  892. From: JOHN HEIM                                             Time: 11:41 pm
  893.   To: ALL                                                   (Read 95 times)
  894. Subj: STUFF
  895.  
  896. In case anyone missed my previous message, I'd like to reiterate that if
  897. anyone out there wants to get Borland tech support from a BBS I'd suggest
  898. you go for CompuServe instead of BIX.  I've found it infinately more
  899. intuitive and user friendly.
  900.  
  901. BBS support is a very useful tool.  If you've ever tried discribing your
  902. code to someone on the phone you may be able to imagine how convenient
  903. being able to upload a message could be.  You can include source code,
  904. output listing, commentary etc.
  905.  
  906. One more thing, I subscribe to a magazine called *The C Users Journal*.
  907. It's a great mag and I'd highly recommend it.  It's much better than DDJ
  908. or Computer Journal.  Anybody know of any other good mags we should be
  909. aware of?
  910.  
  911. John Heim
  912. ---------------
  913.  
  914. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DJS1407 Date: 09/15/89
  915. From: JOHN HEIM                                             Time: 11:23 pm
  916.   To: MICHAEL KUMBERA (Rcvd)                                (Read 97 times)
  917. Subj: R: NEURAL NET'S
  918.  
  919. Michael,
  920.  
  921. I signed up for BIX a few weeks ago to talk to Borland's tech support
  922. staff.  I don't really know how to find the stuff your asking for but I
  923. guess I can figure it out.  I'll let you know when I find it.
  924.  
  925. John Heim
  926.  
  927. PS.  I signed up for BIX but I also got a membership on CompuServe where
  928. Borland also suppies a support staff.  I've used CompuServe almost
  929. exclusively since because I found it infinately more user friendly and
  930. intuitive.  I say thsi not necessarily for your benefit, Michael, but just
  931. to let anyone who might be paging through here know.
  932. ---------------
  933.  
  934. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DJR2496 Date: 09/15/89
  935. From: JOHN ABATTE                                           Time: 10:41 pm
  936.   To: ALL                                                   (Read 96 times)
  937. Subj: DEREFERENCING POINTERS
  938.  
  939. What exactly does it mean to dereference a pointer. I'm new to C and I've
  940. heard the term several times, but I haven't the foggiest idea what it
  941. means or what it's used for. I'm taking a second-level course at the local
  942. college and the question was brought up, but the instructor didn't give a
  943. very good explanation. I'd appreciate it if anyone could clarify this for
  944. me Thanks for the help.
  945. Ciao for now...John
  946. ---------------
  947.  
  948. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DJP1645 Date: 09/15/89
  949. From: GRANT ELLSWORTH (Leader)                              Time: 08:27 pm
  950.   To: ROBERT BALSOVER (Rcvd)                                (Read 98 times)
  951. Subj: R: CALLABLE EDITOR IN C
  952.  
  953. Bob, there was ONE good one of the whole batch ... and that was TPTC17 of
  954. May 88 = from Sam Smith, Tool Shop BBS in Phoenix, AZ.  I think the file
  955. is still here in the Mahoney Collection.  It did have some shortcomings,
  956. but it was SOOOO much better than the others.  And I don't think it puked
  957. on most stuff.   There are some obtuse and arcane constructs it doesn't
  958. handle very well, however (nested structures, untyped variables). But, I
  959. found that the C code it produced was not far from what was needed for  a
  960. clean C compile and execution.  Also, the author released the SOURCE for
  961. that version so you could modify it to meet your needs (source was in TP),
  962.   grant
  963. ---------------
  964.  
  965. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DJC1241 Date: 09/15/89
  966. From: STEVEN KEY                                            Time: 08:20 am
  967.   To: VICTOR DURA (Rcvd)                                    (Read 99 times)
  968. Subj: R: CALLABLE EDITOR IN C
  969.  
  970. Victor,
  971.  
  972. Ed Ream ( advertizes in DDJ) used to sell an editor ( with source )
  973. written in C. It was called RED, I think.  You might give him a call or
  974. drop him a note.
  975.  
  976. Steven
  977. ---------------
  978.  
  979. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DJA1482 Date: 09/15/89
  980. From: VICTOR DURA                                           Time: 06:24 am
  981.   To: GRANT ELLSWORTH (Rcvd)                                (Read 99 times)
  982. Subj: R: CALLABLE EDITOR IN C
  983.  
  984. Thanks for the info Grant, I see what I can find on the Tool Box..Vic
  985. ---------------
  986.  
  987. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DIQ2990 Date: 09/14/89
  988. From: ROBERT BALSOVER                                       Time: 09:49 pm
  989.   To: GRANT ELLSWORTH (Rcvd)                                (Read 99 times)
  990. Subj: R: CALLABLE EDITOR IN C
  991.  
  992. Have you ever tried to use those Pascal->C translators?  They puke on
  993. the code more often then not.  They are not very useful.
  994. Bob
  995. ---------------
  996.  
  997. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DIP1736 Date: 09/14/89
  998. From: OTTO PORTER                                           Time: 08:28 pm
  999.   To: JAMES MACHADO (Rcvd)                                  (Read 105 times)
  1000. Subj: R: PROBLEMS RUNNING QUICK-C
  1001.  
  1002. James,
  1003. I don't know what version you are using, but if it is version 1.00 there
  1004. was a problem a disk control■≥ler ( I fºMforget which).■≥  MS issued
  1005. a maintanence upgrade (v 1.01b) which fixed it.  I don't ■≥know ■≥if
  1006. ■≥you ca■┬√ still get it from them √■≥ without ■≥going to version
  1007. 2.
  1008. Otto P■≥.
  1009. ■≥
  1010. ---------------
  1011.  
  1012. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DHS0692 Date: 09/13/89
  1013. From: GRANT ELLSWORTH (Leader)                              Time: 11:11 pm
  1014.   To: VICTOR DURA (Rcvd)                                    (Read 106 times)
  1015. Subj: R: CALLABLE EDITOR IN C
  1016.  
  1017. Here;s something that might help.  Borland used to sell, and may still
  1018. sell, the Editor Tool Box for Turbo Pascal (4.0).  I don't think they up-
  1019. graded it for 5.0 and/or 5.5.  However, functionally, it can be modified
  1020. to provide this thing you want --- that was the intention of the product.
  1021. Now, you need/want something in C --- so you could run a Pascal to C
  1022. translator (Like TPTC17G(?).ZIP in mahoney collection) against the PASCAL
  1023. source to give you a C version you could work with.  Grant
  1024. ---------------
  1025.  
  1026. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DHG0587 Date: 09/13/89
  1027. From: VICTOR DURA                                           Time: 12:09 pm
  1028.   To: ALL                                                   (Read 104 times)
  1029. Subj: CALLABLE EDITOR IN C
  1030.  
  1031.   Does anyone know of a shareware editor module, written in C, that
  1032. can be called from within a C program? All I need are very simple
  1033. editing functions, nothing fancy. What I would like to do is
  1034. edit a text buffer by passing a pointer to an editor module. E.g.
  1035. the statement  "status=editor(buffptr);" would execute a full
  1036. screen editor on the text at buffptr.
  1037.   Thanks for your help.
  1038. ---------------
  1039.  
  1040. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DGS3152 Date: 09/12/89
  1041. From: RICHARD POELING                                       Time: 11:52 pm
  1042.   To: ERIK DUFEK (Rcvd)                                     (Read 96 times)
  1043. Subj: R: POWER C COMPILER & C/UTILITIES
  1044.  
  1045. I'm sure my code is fine.  Not only that, but like I said before, the
  1046. problem occurs more frequently when I run THEIR programs which I have no
  1047. control over.  So the bugs are with their software.  This weekend I'm
  1048. going to run some test and determine whether it is the compiler that has
  1049. bugs or the C/Utilities that do, or both.
  1050. ---------------
  1051.  
  1052. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DGR2795 Date: 09/12/89
  1053. From: GRANT ELLSWORTH (Leader)                              Time: 10:46 pm
  1054.   To: OTTO PORTER (Rcvd)                                    (Read 100 times)
  1055. Subj: R: PRINTING IN 'C'
  1056.  
  1057. Otto, your description of the form-feed behavior reads like it has more to
  1058. do with the printer than the dos buffers.  The printer may have its own
  1059. little buffer and be running 1 cycle behind what you and the cpu believe
  1060. is the case.  I have the same problem with my NEC pinwriter P3.
  1061.  
  1062. BTW, I think "writing to a file" , which some of our other correspondents
  1063. have suggested, IS definitely the way to do it.  Grant
  1064. ---------------
  1065.  
  1066. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DG11015 Date: 09/12/89
  1067. From: ERIK DUFEK                                            Time: 01:16 am
  1068.   To: RICHARD POELING (Rcvd)                                (Read 99 times)
  1069. Subj: R: POWER C COMPILER & C/UTILITIES
  1070.  
  1071. Are you sure it's Mix's code that is causing the trouble and not yours?
  1072. As far as the Toolchest, I believe they only marketed it.  I believe the
  1073. actual code belongs to someone else.  But I'm not sure about that.
  1074. ---------------
  1075.  
  1076. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DFS2697 Date: 09/11/89
  1077. From: RICHARD POELING                                       Time: 11:44 pm
  1078.   To: ERIK DUFEK (Rcvd)                                     (Read 98 times)
  1079. Subj: POWER C COMPILER & C/UTILITIES
  1080.  
  1081. Thanks for the reply, Erik.  In regards to the version of my Power C
  1082. compiler I received their 1.3.0 upgrade about two months ago.  At the same
  1083. time I also purchased their C/Utilities Toolchest.  It is a collection of
  1084. Unix-like programs that I enjoy using, because most of my computer
  1085. experience is on that type of operating system.  Anyway, I am positive
  1086. that my 'C' source code is accurate because the problems that I am having
  1087. are too transient - I can never tell when it will bomb.
  1088.  
  1089. Actually, I don't usually have too much problem with my programs.  Most of
  1090. my problems occur when I use their Unix-like utilities that they compiled
  1091. with Power C (at least I assume they used their own compiler).  So ther
  1092. must be a bug either in the code they wrote for their utilities or in
  1093. their compiler.
  1094.  
  1095. I think what intrigues me the most is the way that I'm able to get my
  1096. system up and running by using that tsrcom program that is on this BBS.
  1097. Since I run the program in my autoexec.bat file all I have to do is type
  1098. in the command release (which clears out the memory up to the point where
  1099. it was marked) and then run the command mark (so that it re-marks the
  1100. memory in case of another bomb).
  1101.  
  1102. I only wish I knew why I am having this strange problem with just Mix's
  1103. programs.  It seems to me that they didn't test their stuff very
  1104. thoroughly.
  1105. ---------------
  1106.  
  1107. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DF12360 Date: 09/11/89
  1108. From: JAMES MACHADO                                         Time: 01:39 am
  1109.   To: ALL                                                   (Read 103 times)
  1110. Subj: PROBLEMS RUNNING QUICK-C
  1111.  
  1112. Hi i'm wondering if anybody has had a problem getting the Quick-C
  1113. environment to run on an XT with Phenix BIOS running MS-DOS 3.2 (yes it is
  1114. a clone). i've been able to run it on other XT's (also clones) but not my
  1115. own. QCL works, i've used it but when i load QC my hard drive whirs, the
  1116. screen blanks then it locks up. please help
  1117.  james
  1118. ---------------
  1119.  
  1120. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DF10460 Date: 09/11/89
  1121. From: ERIK DUFEK                                            Time: 12:07 am
  1122.   To: RICHARD POELING (Rcvd)                                (Read 99 times)
  1123. Subj: R: #1)POWER C  #2)WORD PROCESSING
  1124.  
  1125. Almost forgot to answer your word processing question.  Look up the issue
  1126. of PC Magazine that has the editor TED in it.  There is some of the
  1127. philosophy of how to program text tools along with the description of the
  1128. TED program.
  1129. ---------------
  1130.  
  1131. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DF10219 Date: 09/11/89
  1132. From: ERIK DUFEK                                            Time: 12:03 am
  1133.   To: RICHARD POELING (Rcvd)                                (Read 100 times)
  1134. Subj: R: #1)POWER C  #2)WORD PROCESSING
  1135.  
  1136. Rick, I have also purchased Mix's Power C as an inexpensive compiler.  I'd
  1137. venture to say I'm not as experienced as you since I've only finished one
  1138. real short program.  But I'm also ahead of you since it compiled and works
  1139. perfectly.  I can't tell you why the program doesn't work on your system.
  1140. It sounds like you may have some incorrect code somewhere.  Do you have a
  1141. later version than 1.10?  I just received an offer in the mail for 3.0 I
  1142. believe it was.
  1143.  
  1144. Are you calling via PCP?  The reason I asked is I'd be happy to try and
  1145. compile your program using my version and see what happens.  I usually
  1146. have a program called BackMail running so that I can transfer programs
  1147. privately, quickly, cheaply and unattended.  Let me know if I can be of
  1148. any help.
  1149. ---------------
  1150.  
  1151. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DEQ3130 Date: 09/10/89
  1152. From: MICHAEL KUMBERA                                       Time: 09:52 pm
  1153.   To: ALL                                                   (Read 94 times)
  1154. Subj: NEURAL NET'S
  1155.  
  1156. Hi,
  1157.  
  1158.   Does and one have access to BIX. I would like a program I heard they
  1159. had. It's a Neural net. that uses back-propagation to learn. The issue was
  1160. Oct. 87. Also if anyone has any other neural network programs the have
  1161. written in C please upload them. (I did see the TTT*.C programs)
  1162.  
  1163.  
  1164. thanks,
  1165.     Michael Kumbera
  1166. ---------------
  1167.  
  1168. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DEK1171 Date: 09/10/89
  1169. From: RICHARD POELING                                       Time: 04:19 pm
  1170.   To: ALL                                                   (Read 103 times)
  1171. Subj: #1)POWER C  #2)WORD PROCESSING
  1172.  
  1173. Hello, I'm a new member to this conference, but I've been using 'C' on and
  1174. off for about two years.  I originally taught myself the language on a
  1175. Tandy 6000 Xenix system, thus my exposure to writing code in the MSDOS
  1176. environment (and PC) is a bit limited.  I have read through most of the
  1177. messages that are in this section and feel that I should be able to fit in
  1178. without any problem.  Unlike most of you who use either Microsoft's C
  1179. compiler or Quick C I purchased Mix's Power C.  I have found that it can
  1180. do nearly everything (if not everything) that the others can do with the
  1181. exclusion of its lack of being able to produce modules other than Medium
  1182. size.  But before you go and buy yourself a copy OR their C/Utilities
  1183. program, you might want to consider the following situation.  For some
  1184. reason (I haven't been able to find out yet), my system sort of locks up
  1185. when I use the compiler or the utilities.  I'm still able to enter
  1186. commands, however programs compiled with the compiler don't run.  All my
  1187. other programs run without a problem, but ever once in a while those
  1188. programs compiled with Power C do nothing but give me the prompt back.  I
  1189. haven't yet contacted Mix Software about this, because I wasn't sure if
  1190. any of my other programs did it (meaning that it might be my computer -
  1191. which it still could be).  However it seems strange that I only have
  1192. problem with Power C compiled software.  The only way I am able to get
  1193. those programs to execute properly is to reboot the system or use the
  1194. tsrcom program that I found on the Mahoney collection.  What it does is
  1195. mark the memory when I boot up.  Then if I start having problems with the
  1196. programs compiled under Power C, I use the release program which I think
  1197. puts the system back the way it was when I booted up.  I then mark the
  1198. memory again with the tsrcom programs and I'm up and running again.  For
  1199. the meantime I am able to live with this inconvenience of having to
  1200. release and mark the memory each time the programs freak out.  Although I
  1201. the lock up problem is transient, there is definitly one thing that always
  1202. causes the Power C compiled programs not to work.  There is a menu program
  1203. in the Mahoney Collection called Power Menu.  I like this program very
  1204. much because it makes launching programs very, very easy.  However if I
  1205. use it, none of the Power C compiled programs will execute.  I have to do
  1206. that release/mark thing, but only after I complete exit Power Menu, which
  1207. I don't like having to do.  So I guess what I'm saying is that Power C is
  1208. a good compiler that is real inexpensive, but there might be some bugs.
  1209. (By the way if anyone might know what the problem is, I'm all ears!) Now
  1210. that I've finished my little speech, I have a question to throw to those
  1211. of you who are a bit more experienced than I am.  It pertains to word
  1212. processors and the way they handle the editing of data.  Since I am not a
  1213. programmer by trade I am unfamiliar with many of the tricks that famous
  1214. guru's use to efficiently handle various problems.  So when I decided to
  1215. sit down and write a text editor to handle a specific need that I have I
  1216. was stumped when it came to the logic needed to handle inserting and
  1217. deleting text from the document and screen without eating up lots of
  1218. memory.
  1219.  
  1220.  
  1221.  
  1222. To make a long story short, how do word processing programs efficiently
  1223. use memory so that when a person needs to insert/delete a character or a
  1224. whole sentence or even an entire page that it doesn't get the text all
  1225. messed up? I have some ideas of how it might be down.  I thought that
  1226. maybe it might be that for each paragraph there is a pointer to the
  1227. beginning, however, I can't figure out how the program could easily make
  1228. room within a given paragraph without loosing the surrounding text.
  1229.  
  1230.  
  1231.  
  1232. If anyone can follow what I'm getting at, I'd really enjoy hearing from
  1233. you.
  1234.  
  1235.  
  1236.  
  1237. Thanks.
  1238.  
  1239. Rick.
  1240.  
  1241.  
  1242.  
  1243. ---------------
  1244.  
  1245. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DDP2842 Date: 09/09/89
  1246. From: OTTO PORTER                                           Time: 08:47 pm
  1247.   To: GRANT ELLSWORTH (Rcvd)                                (Read 101 times)
  1248. Subj: R: PRINTING IN 'C'
  1249.  
  1250. Grant,
  1251. Actually, I am not sure yet whether I am having a problem with the
  1252. printer's internal buffer or the DOS buffer.  The program pauses
  1253. during execution to allow a paper change.  However the Formfeed I issue
  1254. in the program just before the pause is not being acted on by the printer
  1255. until the keypress which is supposed to resume execution.  This is
  1256. most undesirable behaviour. <grin>.  That's why I suspect the DOS buffer.
  1257. I am using the fprintf function to handle the actual printing 'by string.'
  1258. Otto...
  1259. ---------------
  1260.  
  1261. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DDM3327 Date: 09/09/89
  1262. From: GRANT ELLSWORTH (Leader)                              Time: 06:55 pm
  1263.   To: OTTO PORTER (Rcvd)                                    (Read 97 times)
  1264. Subj: R: PRINTING IN 'C'
  1265.  
  1266. Otto, I think use of the DOS IOCTL function will suffice ... bypassing the
  1267. dos buffers is not necessary here and buys nothing in thruput.  (I'm
  1268. assuming your focus is the PRN directed output).  Grant
  1269. ---------------
  1270.  
  1271. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DDH0248 Date: 09/09/89
  1272. From: OTTO PORTER                                           Time: 01:04 pm
  1273.   To: JOHN HEIM (Rcvd)                                      (Read 97 times)
  1274. Subj: R: PRINTING IN 'C'
  1275.  
  1276. John,
  1277.  
  1278. Thanks for the prompt reply.  I have been using part of your idea in
  1279. order to test (writing the output to a file) the program but hadn't
  1280. thought of doing it for the actual implementation.  I LIKE the idea
  1281. and am going to try it out.
  1282.  
  1283. Thanks again,
  1284. Otto...
  1285. ---------------
  1286.  
  1287. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DDH0035 Date: 09/09/89
  1288. From: OTTO PORTER                                           Time: 01:00 pm
  1289.   To: GRANT ELLSWORTH (Rcvd)                                (Read 98 times)
  1290. Subj: R: PRINTING IN 'C'
  1291.  
  1292. Grant,
  1293. Thanks for the info.  I especially like the approach of building the
  1294. output using vsprintf and then using IOCTL.  All this info is the
  1295. general stuff I was hoping for.  None of my books really touch on
  1296. this much.
  1297.  
  1298. One other thing.  Must I use low-level, and or bios routines to get
  1299. by the DOS buffers?
  1300.  
  1301. Thanks again,
  1302. Otto...
  1303. ---------------
  1304.  
  1305. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DDG2961 Date: 09/09/89
  1306. From: OTTO PORTER                                           Time: 12:49 pm
  1307.   To: PATRICK LEMIRANDE (Rcvd)                              (Read 98 times)
  1308. Subj: R: PRINTING IN 'C'
  1309.  
  1310. Pat,
  1311.  
  1312. Thanks for the help and especially the prompt reply.  This will
  1313. get me going.
  1314. ---------------
  1315.  
  1316. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DDF0985 Date: 09/09/89
  1317. From: JOHN HEIM                                             Time: 11:16 am
  1318.   To: OTTO PORTER (Rcvd)                                    (Read 99 times)
  1319. Subj: R: PRINTING IN 'C'
  1320.  
  1321. Otto,
  1322.  
  1323. If this is a really serious printing program, you might consider sending
  1324. the stuff to file before printing it.  This allows you to print multiple
  1325. copies of the report easily and to reprint it if something goes wrong.
  1326.  
  1327. Use a batch file to run the report program. ie. ...
  1328.  
  1329.    REM Run the report to generate a file called REPORT.TXT
  1330.    REPORT
  1331.    REM Print the file
  1332.    PRINT REPORT.TXT
  1333.  
  1334. This technique does require you to clear out the report files once in a
  1335. while or you'll fill up your disk.
  1336.  
  1337. Another advantage is your program doesn't have to wait for the printer to
  1338. catch up.
  1339.  
  1340. John Heim
  1341.  
  1342. PS.  Multi-user systems (DOS networks and Unix workstations) require you to
  1343. do things this way because you
  1344. can't assume that no one else is using the printer.  They usually include
  1345. a 'spooler' that sends files to the printer in the order that they are
  1346. recieved.
  1347. ---------------
  1348.  
  1349. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DDA2781 Date: 09/09/89
  1350. From: PATRICK LEMIRANDE                                     Time: 06:46 am
  1351.   To: ROBERT BALSOVER (Rcvd)                                (Read 104 times)
  1352. Subj: R: PRINTING IN 'C'
  1353.  
  1354. Robert,
  1355.  
  1356. RE:> fprintf(stdprn, format_string, parms);
  1357.  
  1358.      now this is starting to get fun.
  1359.  
  1360.      Thanks.
  1361.  
  1362. Patrick
  1363. N
  1364.  
  1365.  
  1366.  
  1367. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DDF0985 Date: 09/09/89
  1368. From: JOHN HEIM                                             Time: 11:16 am
  1369.   To: OTTO PORTER (Rcvd)                                    (Read 100 times)
  1370. Subj: R: PRINTING IN 'C'
  1371.  
  1372. Otto,
  1373.  
  1374. If this is a really serious printing program, you might consider sending
  1375. the stuff to file before printing it.  This allows you to print multiple
  1376. copies of the report easily and to reprint it if something goes wrong.
  1377.  
  1378. Use a batch file to run the report program. ie. ...
  1379.  
  1380.    REM Run the report to generate a file called REPORT.TXT
  1381.    REPORT
  1382.    REM Print the file
  1383.    PRINT REPORT.TXT
  1384.  
  1385. This technique does require you to clear out the report files once in a
  1386. while or you'll fill up your disk.
  1387.  
  1388. Another advantage is your program doesn't have to wait for the printer to
  1389. catch up.
  1390.  
  1391. John Heim
  1392.  
  1393. PS.  Multi-user systems (DOS networks and Unix workstations) require you to
  1394. do things this way because you
  1395. can't assume that no one else is using the printer.  They usually include
  1396. a 'spooler' that sends files to the printer in the order that they are
  1397. recieved.
  1398. ---------------
  1399. Following thread
  1400.  
  1401. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DDG2961 Date: 09/09/89
  1402. From: OTTO PORTER                                           Time: 12:49 pm
  1403.   To: PATRICK LEMIRANDE (Rcvd)                              (Read 99 times)
  1404. Subj: R: PRINTING IN 'C'
  1405.  
  1406. Pat,
  1407.  
  1408. Thanks for the help and especially the prompt reply.  This will
  1409. get me going.
  1410. ---------------
  1411. ** Current thread: PRINTING IN 'C'
  1412.  
  1413. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DDH0035 Date: 09/09/89
  1414. From: OTTO PORTER                                           Time: 01:00 pm
  1415.   To: GRANT ELLSWORTH (Rcvd)                                (Read 99 times)
  1416. Subj: R: PRINTING IN 'C'
  1417.  
  1418. Grant,
  1419. Thanks for the info.  I especially like the approach of building the
  1420. output using vsprintf and then using IOCTL.  All this info is the
  1421. general stuff I was hoping for.  None of my books really touch on
  1422. this much.
  1423.  
  1424. One other thing.  Must I use low-level, and or bios routines to get
  1425. by the DOS buffers?
  1426.  
  1427. Thanks again,
  1428. Otto...
  1429. ---------------
  1430. ** Current thread: PRINTING IN 'C'
  1431.  
  1432. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DDH0248 Date: 09/09/89
  1433. From: OTTO PORTER                                           Time: 01:04 pm
  1434.   To: JOHN HEIM (Rcvd)                                      (Read 98 times)
  1435. Subj: R: PRINTING IN 'C'
  1436.  
  1437. John,
  1438.  
  1439. Thanks for the prompt reply.  I have been using part of your idea in
  1440. order to test (writing the output to a file) the program but hadn't
  1441. thought of doing it for the actual implementation.  I LIKE the idea
  1442. and am going to try it out.
  1443.  
  1444. Thanks again,
  1445. Otto...
  1446. ---------------
  1447. ** Current thread: PRINTING IN 'C'
  1448.  
  1449. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DDM3327 Date: 09/09/89
  1450. From: GRANT ELLSWORTH (Leader)                              Time: 06:55 pm
  1451.   To: OTTO PORTER (Rcvd)                                    (Read 98 times)
  1452. Subj: R: PRINTING IN 'C'
  1453.  
  1454. Otto, I think use of the DOS IOCTL function will suffice ... bypassing the
  1455. dos buffers is not necessary here and buys nothing in thruput.  (I'm
  1456. assuming your focus is the PRN directed output).  Grant
  1457. ---------------
  1458. ** Current thread: PRINTING IN 'C'
  1459.  
  1460. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DDP2842 Date: 09/09/89
  1461. From: OTTO PORTER                                           Time: 08:47 pm
  1462.   To: GRANT ELLSWORTH (Rcvd)                                (Read 102 times)
  1463. Subj: R: PRINTING IN 'C'
  1464.  
  1465. Grant,
  1466. Actually, I am not sure yet whether I am having a problem with the
  1467. printer's internal buffer or the DOS buffer.  The program pauses
  1468. during execution to allow a paper change.  However the Formfeed I issue
  1469. in the program just before the pause is not being acted on by the printer
  1470. until the keypress which is supposed to resume execution.  This is
  1471. most undesirable behaviour. <grin>.  That's why I suspect the DOS buffer.
  1472. I am using the fprintf function to handle the actual printing 'by string.'
  1473. Otto...
  1474. ---------------
  1475. ** Current thread: PRINTING IN 'C'
  1476.  
  1477. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DGR2795 Date: 09/12/89
  1478. From: GRANT ELLSWORTH (Leader)                              Time: 10:46 pm
  1479.   To: OTTO PORTER (Rcvd)                                    (Read 101 times)
  1480. Subj: R: PRINTING IN 'C'
  1481.  
  1482. Otto, your description of the form-feed behavior reads like it has more to
  1483. do with the printer than the dos buffers.  The printer may have its own
  1484. little buffer and be running 1 cycle behind what you and the cpu believe
  1485. is the case.  I have the same problem with my NEC pinwriter P3.
  1486.  
  1487. BTW, I think "writing to a file" , which some of our other correspondents
  1488. have suggested, IS definitely the way to do it.  Grant
  1489. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  1490.  
  1491. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DEK1171 Date: 09/10/89
  1492. From: RICHARD POELING                                       Time: 04:19 pm
  1493.   To: ALL                                                   (Read 104 times)
  1494. Subj: #1)POWER C  #2)WORD PROCESSING
  1495.  
  1496. Hello, I'm a new member to this conference, but I've been using 'C' on and
  1497. off for about two years.  I originally taught myself the language on a
  1498. Tandy 6000 Xenix system, thus my exposure to writing code in the MSDOS
  1499. environment (and PC) is a bit limited.  I have read through most of the
  1500. messages that are in this section and feel that I should be able to fit in
  1501. without any problem.  Unlike most of you who use either Microsoft's C
  1502. compiler or Quick C I purchased Mix's Power C.  I have found that it can
  1503. do nearly everything (if not everything) that the others can do with the
  1504. exclusion of its lack of being able to produce modules other than Medium
  1505. size.  But before you go and buy yourself a copy OR their C/Utilities
  1506. program, you might want to consider the following situation.  For some
  1507. reason (I haven't been able to find out yet), my system sort of locks up
  1508. when I use the compiler or the utilities.  I'm still able to enter
  1509. commands, however programs compiled with the compiler don't run.  All my
  1510. other programs run without a problem, but ever once in a while those
  1511. programs compiled with Power C do nothing but give me the prompt back.  I
  1512. haven't yet contacted Mix Software about this, because I wasn't sure if
  1513. any of my other programs did it (meaning that it might be my computer -
  1514. which it still could be).  However it seems strange that I only have
  1515. problem with Power C compiled software.  The only way I am able to get
  1516. those programs to execute properly is to reboot the system or use the
  1517. tsrcom program that I found on the Mahoney collection.  What it does is
  1518. mark the memory when I boot up.  Then if I start having problems with the
  1519. programs compiled under Power C, I use the release program which I think
  1520. puts the system back the way it was when I booted up.  I then mark the
  1521. memory again with the tsrcom programs and I'm up and running again.  For
  1522. the meantime I am able to live with this inconvenience of having to
  1523. release and mark the memory each time the programs freak out.  Although I
  1524. the lock up problem is transient, there is definitly one thing that always
  1525. causes the Power C compiled programs not to work.  There is a menu program
  1526. in the Mahoney Collection called Power Menu.  I like this program very
  1527. much because it makes launching programs very, very easy.  However if I
  1528. use it, none of the Power C compiled programs will execute.  I have to do
  1529. that release/mark thing, but only after I complete exit Power Menu, which
  1530. I don't like having to do.  So I guess what I'm saying is that Power C is
  1531. a good compiler that is real inexpensive, but there might be some bugs.
  1532. (By the way if anyone might know what the problem is, I'm all ears!) Now
  1533. that I've finished my little speech, I have a question to throw to those
  1534. of you who are a bit more experienced than I am.  It pertains to word
  1535. processors and the way they handle the editing of data.  Since I am not a
  1536. programmer by trade I am unfamiliar with many of the tricks that famous
  1537. guru's use to efficiently handle various problems.  So when I decided to
  1538. sit down and write a text editor to handle a specific need that I have I
  1539. was stumped when it came to the logic needed to handle inserting and
  1540. deleting text from the document and screen without eating up lots of
  1541. memory.
  1542.  
  1543.  
  1544.  
  1545. To make a long story short, how do word processing programs efficiently
  1546. use memory so that when a person needs to insert/delete a character or a
  1547. whole sentence or even an entire page that it doesn't get the text all
  1548. messed up? I have some ideas of how it might be down.  I thought that
  1549. maybe it might be that for each paragraph there is a pointer to the
  1550. beginning, however, I can't figure out how the program could easily make
  1551. room within a given paragraph without loosing the surrounding text.
  1552.  
  1553.  
  1554.  
  1555. If anyone can follow what I'm getting at, I'd really enjoy hearing from
  1556. you.
  1557.  
  1558.  
  1559.  
  1560. Thanks.
  1561.  
  1562. Rick.
  1563.  
  1564.  
  1565.  
  1566. ---------------
  1567. Following thread
  1568.  
  1569. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DF10219 Date: 09/11/89
  1570. From: ERIK DUFEK                                            Time: 12:03 am
  1571.   To: RICHARD POELING (Rcvd)                                (Read 101 times)
  1572. Subj: R: #1)POWER C  #2)WORD PROCESSING
  1573.  
  1574. Rick, I have also purchased Mix's Power C as an inexpensive compiler.  I'd
  1575. venture to say I'm not as experienced as you since I've only finished one
  1576. real short program.  But I'm also ahead of you since it compiled and works
  1577. perfectly.  I can't tell you why the program doesn't work on your system.
  1578. It sounds like you may have some incorrect code somewhere.  Do you have a
  1579. later version than 1.10?  I just received an offer in the mail for 3.0 I
  1580. believe it was.
  1581.  
  1582. Are you calling via PCP?  The reason I asked is I'd be happy to try and
  1583. compile your program using my version and see what happens.  I usually
  1584. have a program called BackMail running so that I can transfer programs
  1585. privately, quickly, cheaply and unattended.  Let me know if I can be of
  1586. any help.
  1587. ---------------
  1588. ** Current thread: #1)POWER C  #2)WORD PROCESSING
  1589.  
  1590. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DF10460 Date: 09/11/89
  1591. From: ERIK DUFEK                                            Time: 12:07 am
  1592.   To: RICHARD POELING (Rcvd)                                (Read 100 times)
  1593. Subj: R: #1)POWER C  #2)WORD PROCESSING
  1594.  
  1595. Almost forgot to answer your word processing question.  Look up the issue
  1596. of PC Magazine that has the editor TED in it.  There is some of the
  1597. philosophy of how to program text tools along with the description of the
  1598. TED program.
  1599. ---------------
  1600. ** Current thread: #1)POWER C  #2)WORD PROCESSING
  1601.  
  1602. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DNQ1473 Date: 09/19/89
  1603. From: JIM MONROE                                            Time: 09:24 pm
  1604.   To: RICHARD POELING (Rcvd)                                (Read 97 times)
  1605. Subj: R: #1)POWER C  #2)WORD PROCESSING
  1606.  
  1607. I ALSO HAVE THE POWERC C PACKAGE FROM MIX.  I have not had any problems
  1608. with the programs. If possible can you upload one tof these to me and I
  1609. will try it here to see if the same problem exsists.
  1610. Jim
  1611. //
  1612. s
  1613. ---------------
  1614. ** Current thread: #1)POWER C  #2)WORD PROCESSING
  1615.  
  1616. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DNQ1620 Date: 09/19/89
  1617. From: JIM MONROE                                            Time: 09:27 pm
  1618.   To: ERIK DUFEK (Rcvd)                                     (Read 97 times)
  1619. Subj: R: #1)POWER C  #2)WORD PROCESSING
  1620.  
  1621. I also have the powerc c compiler and have no problem. Is it possible to
  1622. get a mix group together on this board?
  1623. ---------------
  1624. ** Current thread: #1)POWER C  #2)WORD PROCESSING
  1625.  
  1626. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DNR3544 Date: 09/19/89
  1627. From: ERIK DUFEK                                            Time: 10:59 pm
  1628.   To: JIM MONROE (Rcvd)                                     (Read 95 times)
  1629. Subj: R: #1)POWER C  #2)WORD PROCESSING
  1630.  
  1631. >Is it possible to
  1632. >get a mix group together on this board?
  1633.  
  1634. Bob is waiting for the move before he does any more work in modifying the
  1635. topic areas.  But I think the C area is an appropriate area.  C is meant
  1636. to be portable so any discussion should usually be relevant with any
  1637. compiler.
  1638.  
  1639. I'm not a serious user of the program yet.  I've used it a few times, but
  1640. nothing complicated.  I've downloaded a few of the C tutors though in
  1641. anticipation of more serious use in the future.
  1642. ---------------
  1643. ** Current thread: #1)POWER C  #2)WORD PROCESSING
  1644.  
  1645. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DPD2900 Date: 09/20/89
  1646. From: JIM MONROE                                            Time: 09:48 am
  1647.   To: ERIK DUFEK (Rcvd)                                     (Read 102 times)
  1648. Subj: R: #1)POWER C  #2)WORD PROCESSING
  1649.  
  1650. I think that both a discussion group here on the BBS as well as some
  1651. degree of personnel interaction may be valuable. Lets try it later in the
  1652. fall.
  1653. ---------------
  1654. ** Current thread: #1)POWER C  #2)WORD PROCESSING
  1655.  
  1656. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DPS3196 Date: 09/20/89
  1657. From: ERIK DUFEK                                            Time: 11:53 pm
  1658.   To: JIM MONROE (Rcvd)                                     (Read 96 times)
  1659. Subj: R: #1)POWER C  #2)WORD PROCESSING
  1660.  
  1661. In any type of C discussion, I expect I'll be the slow guy.
  1662. ---------------
  1663. ** Current thread: #1)POWER C  #2)WORD PROCESSING
  1664.  
  1665. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DRP1898 Date: 09/22/89
  1666. From: RICHARD POELING                                       Time: 08:31 pm
  1667.   To: JIM MONROE (Rcvd)                                     (Read 99 times)
  1668. Subj: R: #1)POWER C  #2)WORD PROCESSING
  1669.  
  1670. After testing some things on my system, I have concluded that my programs
  1671. run fine when I compile them with Power C.  The source of all my problems
  1672. seems to be the Utilities that I bought from Mix.  I don't know if it is a
  1673. problem with my computer not liking the way their stuff was compiled or
  1674. what exactly, but eventually I find it.
  1675. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  1676.  
  1677. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DEQ3130 Date: 09/10/89
  1678. From: MICHAEL KUMBERA                                       Time: 09:52 pm
  1679.   To: ALL                                                   (Read 95 times)
  1680. Subj: NEURAL NET'S
  1681.  
  1682. Hi,
  1683.  
  1684.   Does and one have access to BIX. I would like a program I heard they
  1685. had. It's a Neural net. that uses back-propagation to learn. The issue was
  1686. Oct. 87. Also if anyone has any other neural network programs the have
  1687. written in C please upload them. (I did see the TTT*.C programs)
  1688.  
  1689.  
  1690. thanks,
  1691.     Michael Kumbera
  1692. ---------------
  1693. Following thread
  1694.  
  1695. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DJS1407 Date: 09/15/89
  1696. From: JOHN HEIM                                             Time: 11:23 pm
  1697.   To: MICHAEL KUMBERA (Rcvd)                                (Read 98 times)
  1698. Subj: R: NEURAL NET'S
  1699.  
  1700. Michael,
  1701.  
  1702. I signed up for BIX a few weeks ago to talk to Borland's tech support
  1703. staff.  I don't really know how to find the stuff your asking for but I
  1704. guess I can figure it out.  I'll let you know when I find it.
  1705.  
  1706. John Heim
  1707.  
  1708. PS.  I signed up for BIX but I also got a membership on CompuServe where
  1709. Borland also suppies a support staff.  I've used CompuServe almost
  1710. exclusively since because I found it infinately more user friendly and
  1711. intuitive.  I say thsi not necessarily for your benefit, Michael, but just
  1712. to let anyone who might be paging through here know.
  1713. ---------------
  1714. ** Current thread: NEURAL NET'S
  1715.  
  1716. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DKK1262 Date: 09/16/89
  1717. From: MICHAEL KUMBERA                                       Time: 04:21 pm
  1718.   To: JOHN HEIM (Rcvd)                                      (Read 95 times)
  1719. Subj: R: NEURAL NET'S
  1720.  
  1721. Thanks for the reply John.
  1722.  
  1723. I found some information that might help you locate the file.
  1724. The Issue was Oct. 87 and the program name is bpsim.c also the artical
  1725. name is "Back-Propagation, A Generalized delta learning rule".
  1726.  
  1727.  
  1728. Thanks for taking the time to look for the file.
  1729.  
  1730. Michael Kumbera
  1731. ---------------
  1732. ** Current thread: NEURAL NET'S
  1733.  
  1734. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DNP1072 Date: 09/19/89
  1735. From: JOHN HEIM                                             Time: 08:17 pm
  1736.   To: MICHAEL KUMBERA (Rcvd)                                (Read 95 times)
  1737. Subj: NEURAL NET'S
  1738.  
  1739. Michael,
  1740.  
  1741. I got on BIX and looked for the code listings for October 87.  Well, I
  1742. couldn't find them.  I found Oct '88 and even Oct '89 but not Oct '87.  I
  1743. think they're not there.  Maybe there's someone on this BBS that uses BIX
  1744. alot who can say for sure.  I looked around for quite a while before
  1745. giving up.  Do you have some reason for believing it was there?
  1746.  
  1747. John Heim
  1748. ---------------
  1749. ** Current thread: NEURAL NET'S
  1750.  
  1751. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DNR0139 Date: 09/19/89
  1752. From: MICHAEL KUMBERA                                       Time: 10:02 pm
  1753.   To: JOHN HEIM (Rcvd)                                      (Read 99 times)
  1754. Subj: R: NEURAL NET'S
  1755.  
  1756. John,
  1757.  
  1758. The reason I think it's there is that the BYTE article states that the
  1759. program can be downloaded from BIX. I would like to thank you for looking
  1760. though.
  1761.  
  1762.  
  1763. Michael Kumbera
  1764. ---------------
  1765. ** Current thread: NEURAL NET'S
  1766.  
  1767. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DVQ2172 Date: 09/26/89
  1768. From: JOHN HEIM                                             Time: 09:36 pm
  1769.   To: MICHAEL KUMBERA (Rcvd)                                (Read 99 times)
  1770. Subj: R: NEURAL NET'S
  1771.  
  1772. Michael,
  1773.  
  1774. It's really been bugging me that I couldn't find your BIX stuff.  I'm
  1775. going to poke around again when I get the time.  If you have success
  1776. through other means let me know.  I was thinking that they might remove
  1777. code listings after a certain period of time.
  1778.  
  1779. John
  1780. ---------------
  1781. ** Current thread: NEURAL NET'S
  1782.  
  1783. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2E5N1869 Date: 10/05/89
  1784. From: MICHAEL KUMBERA                                       Time: 07:31 pm
  1785.   To: JOHN HEIM (Rcvd)                                      (Read 105 times)
  1786. Subj: R: NEURAL NET'S
  1787.  
  1788. John,
  1789.  
  1790.  Sorry about the delay in replying to you message...
  1791.  
  1792.  I managed to find a copy of bpsim.c about 2 day's ago. A systems
  1793. programmer had a copy of it in here directory for several years.
  1794. I asked here for any Neural Network programs she had and she sent it to
  1795. me.
  1796.  
  1797. THANKS A LOT,
  1798.  
  1799. Mike Kumbera
  1800. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  1801.  
  1802. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DF12360 Date: 09/11/89
  1803. From: JAMES MACHADO                                         Time: 01:39 am
  1804.   To: ALL                                                   (Read 104 times)
  1805. Subj: PROBLEMS RUNNING QUICK-C
  1806.  
  1807. Hi i'm wondering if anybody has had a problem getting the Quick-C
  1808. environment to run on an XT with Phenix BIOS running MS-DOS 3.2 (yes it is
  1809. a clone). i've been able to run it on other XT's (also clones) but not my
  1810. own. QCL works, i've used it but when i load QC my hard drive whirs, the
  1811. screen blanks then it locks up. please help
  1812.  james
  1813. ---------------
  1814. Following thread
  1815.  
  1816. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DIP1736 Date: 09/14/89
  1817. From: OTTO PORTER                                           Time: 08:28 pm
  1818.   To: JAMES MACHADO (Rcvd)                                  (Read 106 times)
  1819. Subj: R: PROBLEMS RUNNING QUICK-C
  1820.  
  1821. James,
  1822. I don't know what version you are using, but if it is version 1.00 there
  1823. was a problem a disk control■≥ler ( I fºMforget which).■≥  MS issued
  1824. a maintanence upgrade (v 1.01b) which fixed it.  I don't ■≥know ■≥if
  1825. ■≥you ca■┬√ still get it from them √■≥ without ■≥going to version
  1826. 2.
  1827. Otto P■≥.
  1828. ■≥
  1829. ---------------
  1830. ** Current thread: PROBLEMS RUNNING QUICK-C
  1831.  
  1832. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DS13355 Date: 09/23/89
  1833. From: JAMES MACHADO                                         Time: 12:55 am
  1834.   To: OTTO PORTER (Rcvd)                                    (Read 103 times)
  1835. Subj: R: PROBLEMS RUNNING QUICK-C
  1836.  
  1837. i have 1.00 and 2, i only had the problem with 2, i ended up changing my
  1838. dos from an old generic to dri's e've heard of stranger things, but not
  1839. many. thanks
  1840.  james
  1841. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  1842.  
  1843. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DFS2697 Date: 09/11/89
  1844. From: RICHARD POELING                                       Time: 11:44 pm
  1845.   To: ERIK DUFEK (Rcvd)                                     (Read 99 times)
  1846. Subj: POWER C COMPILER & C/UTILITIES
  1847.  
  1848. Thanks for the reply, Erik.  In regards to the version of my Power C
  1849. compiler I received their 1.3.0 upgrade about two months ago.  At the same
  1850. time I also purchased their C/Utilities Toolchest.  It is a collection of
  1851. Unix-like programs that I enjoy using, because most of my computer
  1852. experience is on that type of operating system.  Anyway, I am positive
  1853. that my 'C' source code is accurate because the problems that I am having
  1854. are too transient - I can never tell when it will bomb.
  1855.  
  1856. Actually, I don't usually have too much problem with my programs.  Most of
  1857. my problems occur when I use their Unix-like utilities that they compiled
  1858. with Power C (at least I assume they used their own compiler).  So ther
  1859. must be a bug either in the code they wrote for their utilities or in
  1860. their compiler.
  1861.  
  1862. I think what intrigues me the most is the way that I'm able to get my
  1863. system up and running by using that tsrcom program that is on this BBS.
  1864. Since I run the program in my autoexec.bat file all I have to do is type
  1865. in the command release (which clears out the memory up to the point where
  1866. it was marked) and then run the command mark (so that it re-marks the
  1867. memory in case of another bomb).
  1868.  
  1869. I only wish I knew why I am having this strange problem with just Mix's
  1870. programs.  It seems to me that they didn't test their stuff very
  1871. thoroughly.
  1872. ---------------
  1873. Following thread
  1874.  
  1875. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DG11015 Date: 09/12/89
  1876. From: ERIK DUFEK                                            Time: 01:16 am
  1877.   To: RICHARD POELING (Rcvd)                                (Read 100 times)
  1878. Subj: R: POWER C COMPILER & C/UTILITIES
  1879.  
  1880. Are you sure it's Mix's code that is causing the trouble and not yours?
  1881. As far as the Toolchest, I believe they only marketed it.  I believe the
  1882. actual code belongs to someone else.  But I'm not sure about that.
  1883. ---------------
  1884. ** Current thread: POWER C COMPILER & C/UTILITIES
  1885.  
  1886. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DGS3152 Date: 09/12/89
  1887. From: RICHARD POELING                                       Time: 11:52 pm
  1888.   To: ERIK DUFEK (Rcvd)                                     (Read 97 times)
  1889. Subj: R: POWER C COMPILER & C/UTILITIES
  1890.  
  1891. I'm sure my code is fine.  Not only that, but like I said before, the
  1892. problem occurs more frequently when I run THEIR programs which I have no
  1893. control over.  So the bugs are with their software.  This weekend I'm
  1894. going to run some test and determine whether it is the compiler that has
  1895. bugs or the C/Utilities that do, or both.
  1896. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  1897.  
  1898. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DHG0587 Date: 09/13/89
  1899. From: VICTOR DURA                                           Time: 12:09 pm
  1900.   To: ALL                                                   (Read 105 times)
  1901. Subj: CALLABLE EDITOR IN C
  1902.  
  1903.   Does anyone know of a shareware editor module, written in C, that
  1904. can be called from within a C program? All I need are very simple
  1905. editing functions, nothing fancy. What I would like to do is
  1906. edit a text buffer by passing a pointer to an editor module. E.g.
  1907. the statement  "status=editor(buffptr);" would execute a full
  1908. screen editor on the text at buffptr.
  1909.   Thanks for your help.
  1910. ---------------
  1911. Following thread
  1912.  
  1913. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DHS0692 Date: 09/13/89
  1914. From: GRANT ELLSWORTH (Leader)                              Time: 11:11 pm
  1915.   To: VICTOR DURA (Rcvd)                                    (Read 107 times)
  1916. Subj: R: CALLABLE EDITOR IN C
  1917.  
  1918. Here;s something that might help.  Borland used to sell, and may still
  1919. sell, the Editor Tool Box for Turbo Pascal (4.0).  I don't think they up-
  1920. graded it for 5.0 and/or 5.5.  However, functionally, it can be modified
  1921. to provide this thing you want --- that was the intention of the product.
  1922. Now, you need/want something in C --- so you could run a Pascal to C
  1923. translator (Like TPTC17G(?).ZIP in mahoney collection) against the PASCAL
  1924. source to give you a C version you could work with.  Grant
  1925. ---------------
  1926. ** Current thread: CALLABLE EDITOR IN C
  1927.  
  1928. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DIQ2990 Date: 09/14/89
  1929. From: ROBERT BALSOVER                                       Time: 09:49 pm
  1930.   To: GRANT ELLSWORTH (Rcvd)                                (Read 100 times)
  1931. Subj: R: CALLABLE EDITOR IN C
  1932.  
  1933. Have you ever tried to use those Pascal->C translators?  They puke on
  1934. the code more often then not.  They are not very useful.
  1935. Bob
  1936. ---------------
  1937. ** Current thread: CALLABLE EDITOR IN C
  1938.  
  1939. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DJA1482 Date: 09/15/89
  1940. From: VICTOR DURA                                           Time: 06:24 am
  1941.   To: GRANT ELLSWORTH (Rcvd)                                (Read 100 times)
  1942. Subj: R: CALLABLE EDITOR IN C
  1943.  
  1944. Thanks for the info Grant, I see what I can find on the Tool Box..Vic
  1945. ---------------
  1946. ** Current thread: CALLABLE EDITOR IN C
  1947.  
  1948. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DJC1241 Date: 09/15/89
  1949. From: STEVEN KEY                                            Time: 08:20 am
  1950.   To: VICTOR DURA (Rcvd)                                    (Read 100 times)
  1951. Subj: R: CALLABLE EDITOR IN C
  1952.  
  1953. Victor,
  1954.  
  1955. Ed Ream ( advertizes in DDJ) used to sell an editor ( with source )
  1956. written in C. It was called RED, I think.  You might give him a call or
  1957. drop him a note.
  1958.  
  1959. Steven
  1960. ---------------
  1961. ** Current thread: CALLABLE EDITOR IN C
  1962.  
  1963. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DJP1645 Date: 09/15/89
  1964. From: GRANT ELLSWORTH (Leader)                              Time: 08:27 pm
  1965.   To: ROBERT BALSOVER (Rcvd)                                (Read 99 times)
  1966. Subj: R: CALLABLE EDITOR IN C
  1967.  
  1968. Bob, there was ONE good one of the whole batch ... and that was TPTC17 of
  1969. May 88 = from Sam Smith, Tool Shop BBS in Phoenix, AZ.  I think the file
  1970. is still here in the Mahoney Collection.  It did have some shortcomings,
  1971. but it was SOOOO much better than the others.  And I don't think it puked
  1972. on most stuff.   There are some obtuse and arcane constructs it doesn't
  1973. handle very well, however (nested structures, untyped variables). But, I
  1974. found that the C code it produced was not far from what was needed for  a
  1975. clean C compile and execution.  Also, the author released the SOURCE for
  1976. that version so you could modify it to meet your needs (source was in TP),
  1977.   grant
  1978. ---------------
  1979. ** Current thread: CALLABLE EDITOR IN C
  1980.  
  1981. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DK40892 Date: 09/16/89
  1982. From: ROBERT BALSOVER                                       Time: 04:14 am
  1983.   To: GRANT ELLSWORTH (Rcvd)                                (Read 98 times)
  1984. Subj: R: CALLABLE EDITOR IN C
  1985.  
  1986. Grant,
  1987. I dunno.  I only used Sam's program, I never looked at any others.
  1988. I was attempting to translate the TPascal Editor toolbox and it puked.
  1989. Did he continue developement of his program or shelf it?
  1990. Bob
  1991. ---------------
  1992. ** Current thread: CALLABLE EDITOR IN C
  1993.  
  1994. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DK41916 Date: 09/16/89
  1995. From: ROBERT BALSOVER                                       Time: 04:31 am
  1996.   To: VICTOR DURA (Rcvd)                                    (Read 98 times)
  1997. Subj: R: CALLABLE EDITOR IN C
  1998.  
  1999. Victor,
  2000. There is a file in the collection called TURBBOOK.ZIP.  It contains the
  2001. source from Al stevens Book Turbo C screen O/I (etc. something like
  2002. that)  I have that book and in it he wrote a routine that is exactly
  2003. what you asked for.  The source is for TSR's, Windows etc.  The file
  2004. would have the correct book name if you want to pick it up.  I've
  2005. seen it lately on the bookshelfs so you shouldn't have problems finding
  2006. it.  I do recommend the book but it is written for TC 1.0 so you
  2007. have to make adjustments if you wish to do TSR's with a later version
  2008. of TC.  It otherwise needs no further corrections.
  2009. Bob
  2010. ---------------
  2011. ** Current thread: CALLABLE EDITOR IN C
  2012.  
  2013. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DKS1246 Date: 09/16/89
  2014. From: GRANT ELLSWORTH (Leader)                              Time: 11:20 pm
  2015.   To: ROBERT BALSOVER (Rcvd)                                (Read 101 times)
  2016. Subj: R: CALLABLE EDITOR IN C
  2017.  
  2018. Bob, I think tptc17 of may 3(?) 88 was the last shareware version.  The
  2019. source to it was also distributed.  That was the version I was referring
  2020. to.  No, I did not try it out on Borland's Editor Toolbox, but I did use
  2021. it to translate a complex MVS performance measurement tool which I
  2022. developed in TP3.0.  THere were some problems because of the complex
  2023. structures in code and data.  I do remember that a prior version to
  2024. TPTC17(g) of May 88 did "puke" on any complicated pascal program.
  2025.  
  2026. What version did you use - (date and version id)?
  2027.  
  2028. BTW, Sam has not totally abandoned the translator.  I understand it was
  2029. purchased by a company (purchase had Sam attached to it) and that Sam
  2030. is improving it over time with a commercial release as the target.
  2031.  
  2032. You could check with Sam (call the Tool Shop) and find out what current
  2033. plans are.    Grant
  2034. ---------------
  2035. ** Current thread: CALLABLE EDITOR IN C
  2036.  
  2037. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DM13002 Date: 09/18/89
  2038. From: ROBERT BALSOVER                                       Time: 12:50 am
  2039.   To: GRANT ELLSWORTH (Rcvd)                                (Read 96 times)
  2040. Subj: R: CALLABLE EDITOR IN C
  2041.  
  2042. Grant,
  2043. I used what I think was the May '88 version. I can't be sure because I
  2044. erased it when it puked several times. I decided it was not advanced
  2045. enough for my use.
  2046. I have seen a comercial TP2C translator advertised in DDJ June '89.
  2047. Pg #9 is Programmers Paradise's ad. It lists with them for $199.
  2048. I wonder if that is Sam's work.
  2049. Any time I try to call the Tool Shop it is busy.
  2050. Bob
  2051. ---------------
  2052. ** Current thread: CALLABLE EDITOR IN C
  2053.  
  2054. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DNC2722 Date: 09/19/89
  2055. From: VICTOR DURA                                           Time: 08:45 am
  2056.   To: STEVEN KEY (Rcvd)                                     (Read 95 times)
  2057. Subj: R: CALLABLE EDITOR IN C
  2058.  
  2059. Steve, Thanks for the info. I'll check it out...Vic
  2060. ---------------
  2061. ** Current thread: CALLABLE EDITOR IN C
  2062.  
  2063. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DNC2830 Date: 09/19/89
  2064. From: VICTOR DURA                                           Time: 08:47 am
  2065.   To: ROBERT BALSOVER (Rcvd)                                (Read 96 times)
  2066. Subj: R: CALLABLE EDITOR IN C
  2067.  
  2068. Robert
  2069. Thanks for the tip. I dl and check it out.
  2070. Vic
  2071. ---------------
  2072. ** Current thread: CALLABLE EDITOR IN C
  2073.  
  2074. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DNM0451 Date: 09/19/89
  2075. From: GRANT ELLSWORTH (Leader)                              Time: 06:07 pm
  2076.   To: ROBERT BALSOVER (Rcvd)                                (Read 97 times)
  2077. Subj: R: CALLABLE EDITOR IN C
  2078.  
  2079. TP2C is not Sam's commercial version.  I think it is the one put out by
  2080. Chien(?) Associates in New Orleans.  I noticed an ad from them last winter
  2081. when S's s/w was still called TPC or TP2C as well.  Sam and I had a short
  2082. dialogue on his bbs about it ... he knew nothing about Chien or that TP2C.
  2083.  
  2084. BTW, I think any hang you may get in the May 88 version can be easily
  2085. fixed if you also have a Pascal Compiler and the TPTC 17 sources.
  2086.  
  2087. Also, I note that I have to put my machine in autodial for an average of
  2088. 50 mins to get into the Tool Shop ... it certainly is a popular BBS out
  2089. there in the southwest.   Grant
  2090. ---------------
  2091. ** Current thread: CALLABLE EDITOR IN C
  2092.  
  2093. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DNR0939 Date: 09/19/89
  2094. From: ROBERT BALSOVER                                       Time: 10:15 pm
  2095.   To: GRANT ELLSWORTH (Rcvd)                                (Read 98 times)
  2096. Subj: R: CALLABLE EDITOR IN C
  2097.  
  2098. Grant,
  2099. Unfortunately I don't have a Pascal compiler, I never saw a need for it.
  2100. With all of the good Pascal source out there I would certainly be
  2101. willing to pay for a fully functioning translator, but I guess there
  2102. isn't enough people like me out there or there would be a package
  2103. available.  I can program in Pascal, so I could do it manually but
  2104. it takes too long even with a half functioning translator.
  2105. Bob
  2106. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  2107.  
  2108. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DJR2496 Date: 09/15/89
  2109. From: JOHN ABATTE                                           Time: 10:41 pm
  2110.   To: ALL                                                   (Read 97 times)
  2111. Subj: DEREFERENCING POINTERS
  2112.  
  2113. What exactly does it mean to dereference a pointer. I'm new to C and I've
  2114. heard the term several times, but I haven't the foggiest idea what it
  2115. means or what it's used for. I'm taking a second-level course at the local
  2116. college and the question was brought up, but the instructor didn't give a
  2117. very good explanation. I'd appreciate it if anyone could clarify this for
  2118. me Thanks for the help.
  2119. Ciao for now...John
  2120. ---------------
  2121.  
  2122. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DJS2501 Date: 09/15/89
  2123. From: JOHN HEIM                                             Time: 11:41 pm
  2124.   To: ALL                                                   (Read 96 times)
  2125. Subj: STUFF
  2126.  
  2127. In case anyone missed my previous message, I'd like to reiterate that if
  2128. anyone out there wants to get Borland tech support from a BBS I'd suggest
  2129. you go for CompuServe instead of BIX.  I've found it infinately more
  2130. intuitive and user friendly.
  2131.  
  2132. BBS support is a very useful tool.  If you've ever tried discribing your
  2133. code to someone on the phone you may be able to imagine how convenient
  2134. being able to upload a message could be.  You can include source code,
  2135. output listing, commentary etc.
  2136.  
  2137. One more thing, I subscribe to a magazine called *The C Users Journal*.
  2138. It's a great mag and I'd highly recommend it.  It's much better than DDJ
  2139. or Computer Journal.  Anybody know of any other good mags we should be
  2140. aware of?
  2141.  
  2142. John Heim
  2143. ---------------
  2144.  
  2145. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DK10817 Date: 09/16/89
  2146. From: RICHARD POELING                                       Time: 12:13 am
  2147.   To: ALL                                                   (Read 99 times)
  2148. Subj: C & ASSEMBLY LANGUAGE BBS'S
  2149.  
  2150. I am interested in locating other BBS's that have a good 'C' programming
  2151. conference section.  I would also like to find one that deals with
  2152. Assembly language in the MSDOS environment.  Does anyone know of any?
  2153. Thanks.
  2154. Rick.
  2155. ---------------
  2156. Following thread
  2157.  
  2158. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DNP1616 Date: 09/19/89
  2159. From: JOHN HEIM                                             Time: 08:26 pm
  2160.   To: RICHARD POELING (Rcvd)                                (Read 96 times)
  2161. Subj: R: C & ASSEMBLY LANGUAGE BBS'S
  2162.  
  2163. Rick,
  2164.  
  2165. I'm sure CompuServe has conferences on both C and Assembly.  It'll cost you
  2166. some bucks to use though.  Most of the people I know that spend a lot of
  2167. time on CS use a program that logs them on, downloads the messages they're
  2168. interested in and logs them off automatically.  It's available from
  2169. CompuServe.  I don't use CS all that much except to ask Borland's tech
  2170. support staff questions so I don't know that much about it.
  2171.  
  2172. John
  2173. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  2174.  
  2175. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DKK2078 Date: 09/16/89
  2176. From: MICHAEL KUMBERA                                       Time: 04:34 pm
  2177.   To: ALL                                                   (Read 96 times)
  2178. Subj: C++
  2179.  
  2180. If any of you get a chance to use C++ do it. It adds some great new
  2181. functions to C. I recently got the book "Using C++" by Bruce Eckel
  2182. (Osborne McGraw-Hill) and it gives a good explination on how to use C++.
  2183. Their discussion of using OBJECTS is well done but they could explain
  2184. function overloading better. C++ seems like the best programming language
  2185. since C.
  2186.  
  2187.  
  2188. Michael Kumbera
  2189. ---------------
  2190. Following thread
  2191.  
  2192. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AMF2747 Date: 06/18/90
  2193. From: GREGORY WILSON                                        Time: 11:45 am
  2194.   To: ALL                                                   (Read 70 times)
  2195. Subj: C++
  2196.  
  2197. Could someone tell me in 500 words or less what the advantage is in using
  2198. C++ over C.
  2199. Is it more portable?
  2200. Is it faster?
  2201. Will regular C programs compile under C++ compilers?
  2202. Are there any standards in place for C++?
  2203. Is MSC planning on adding C++ to their product?
  2204. Now that I finnaly have a handle on C, is it worth my time to learn C++?
  2205.  
  2206. I would appreciate any information you could give.
  2207. Thanks in advance!!
  2208. Gregory Wilson
  2209. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  2210.  
  2211. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DNQ0696 Date: 09/19/89
  2212. From: JIM FISCHER                                           Time: 09:11 pm
  2213.   To: ALL                                                   (Read 96 times)
  2214. Subj: REPORT WRITING
  2215.  
  2216. Can anybody give me some advice as to editing data used to print a report
  2217. written in 'C'.  I need to know how to edit a numeric field whose length
  2218. can be from 0 to 999,999,999. I need to know how to insert the commas
  2219. between the numbers if the field is long enough to require them.  This
  2220. report is to be printed not displayed on screen.
  2221.                                        Thanks,
  2222.                                            Jim
  2223. ---------------
  2224. Following thread
  2225.  
  2226. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DNS3163 Date: 09/19/89
  2227. From: PAUL MCKENZIE                                         Time: 11:52 pm
  2228.   To: JIM FISCHER (Rcvd)                                    (Read 94 times)
  2229. Subj: R: REPORT WRITING
  2230.  
  2231. Jim, I have a function that returns a comma formatted number.  It works
  2232. with either negative or positive values.  I have the code at my place of
  2233. work, so I cannot get my hands on it until tomorrow (Wednesday).
  2234. The ANSI prototype to the routine is as follows:
  2235.     char *comma_fmt(double num, char *buf)
  2236. where num is the number to format, and buf is a pointer to the buffer that
  2237. will store the formatted number.  The routine also returns the pointer to
  2238. the buffer.
  2239.                                  Paul  McKenzie
  2240. ---------------
  2241. ** Current thread: REPORT WRITING
  2242.  
  2243. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DP11456 Date: 09/20/89
  2244. From: PAUL MCKENZIE                                         Time: 12:24 am
  2245.   To: PAUL MCKENZIE (Rcvd)                                  (Read 99 times)
  2246. Subj: R: REPORT WRITING
  2247.  
  2248. Oops, Got the prototype confused.  The call is as follows:
  2249. char *comma_fmt(char *buf1, char *buf2)
  2250. where buf1 is a pointer to a string representing the number to be
  2251. formatted, and buf2 is a pointer to the buffer where the formatted number
  2252. is to reside.  The routine requires you to convert the original number to
  2253. a string yourself.  You can use sprintf() or your own number to string
  2254. routine.  Here is an example:
  2255.      int num = 23456;
  2256.      char buf2[10]
  2257.      char temp[7];
  2258.      sprintf(temp,"%d",num);
  2259.      comma_fmt(temp,buf2);
  2260.      fprintf(stdprn,"%s",buf2);
  2261.                                         Paul McKenzie
  2262. ---------------
  2263. ** Current thread: REPORT WRITING
  2264.  
  2265. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DPN1096 Date: 09/20/89
  2266. From: JIM FISCHER                                           Time: 07:18 pm
  2267.   To: PAUL MCKENZIE (Rcvd)                                  (Read 100 times)
  2268. Subj: REPORT WRITING
  2269.  
  2270.  Thanks much for your help, we'll give it a try and let you know the
  2271. results.
  2272.  
  2273. Thanks again, Jim
  2274. ---------------
  2275. ** Current thread: REPORT WRITING
  2276.  
  2277. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DQ22927 Date: 09/21/89
  2278. From: PAUL MCKENZIE                                         Time: 02:48 am
  2279.   To: JIM FISCHER (Rcvd)                                    (Read 95 times)
  2280. Subj: R: REPORT WRITING
  2281.  
  2282. Jim, I have uploaded COMMAFMT.ZIP on the Mahoney Collection.  This should
  2283. take care of your problem.
  2284.                                  Paul
  2285. ---------------
  2286. ** Current thread: REPORT WRITING
  2287.  
  2288. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DQL1636 Date: 09/21/89
  2289. From: JIM FISCHER                                           Time: 05:27 pm
  2290.   To: PAUL MCKENZIE (Rcvd)                                  (Read 102 times)
  2291. Subj: REPORT WRITING
  2292.  
  2293.  Paul, much thanks and salutations to you! I'll D/L the file and check it
  2294. out tonight. Really appreciate your help, I owe you one.
  2295.  
  2296. Best regards, Jim
  2297. ---------------
  2298. ** Current thread: REPORT WRITING
  2299.  
  2300. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2EFS1435 Date: 10/11/89
  2301. From: PAUL MCKENZIE                                         Time: 11:23 pm
  2302.   To: JIM FISCHER (Rcvd)                                    (Read 95 times)
  2303. Subj: R: REPORT WRITING
  2304.  
  2305. Jim, I haven't gotten back to you in a few weeks.  Did the function solve
  2306. your problem?
  2307.                                    Paul McKenzie
  2308. ---------------
  2309. ** Current thread: REPORT WRITING
  2310.  
  2311. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2EGN2595 Date: 10/12/89
  2312. From: JIM FISCHER                                           Time: 07:43 pm
  2313.   To: PAUL MCKENZIE (Rcvd)                                  (Read 104 times)
  2314. Subj: REPORT WRITING
  2315.  
  2316.  Yes, thank-you, the function worked like a charm. I'm now presently using
  2317. your function in my program at work.
  2318.  
  2319. Thanks and best regards, Jim
  2320. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  2321.  
  2322. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DS52363 Date: 09/23/89
  2323. From: JOHN LLOYD                                            Time: 05:39 am
  2324.   To: ALL                                                   (Read 97 times)
  2325. Subj: B-TO-C
  2326.  
  2327. A short time ago I downloaded a programs from the Mahoney section called B
  2328. B-to-C.ZIP.  It was for a friend trying to learn C.  While it ran on a
  2329. "Hello World" program, the code generated did not look like any C I have
  2330. seen.  Output seemed to be an intermediate code which needs further
  2331. translation.  I am not a programmer, and could not explain what was going
  2332. on.  First guess is that the program (B-TO-C) was not a complete utility
  2333. by itself, and perhaps files, or librarys were missing.  Anyone know
  2334. anything about this file???  How to use it???  Is there more of it???
  2335. Thanx
  2336. ---------------
  2337. Following thread
  2338.  
  2339. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DV51941 Date: 09/26/89
  2340. From: JOHN LLOYD                                            Time: 05:32 am
  2341.   To: ALL                                                   (Read 96 times)
  2342. Subj: B-TO-C
  2343.  
  2344. Well, I didn't luck out on the B-TO-C.  Does anyone know of a shareware or
  2345. public domain program that with convert, even loosly, a GWBASIC program to
  2346. C source.  A friend is trying to learn C and feels that if he could write
  2347. a small basic program, convert it and study the resultant source code, it
  2348. would help him to understand C more easily.
  2349. ---------------
  2350. ** Current thread: B-TO-C
  2351.  
  2352. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DVQ1861 Date: 09/26/89
  2353. From: GRANT ELLSWORTH (Leader)                              Time: 09:31 pm
  2354.   To: JOHN LLOYD (Rcvd)                                     (Read 97 times)
  2355. Subj: R: B-TO-C
  2356.  
  2357. I remember seeing something named BAS2C.xxx or BASTOC.xxx in the mahoney
  2358. collection some many moons ago.  Check these out.  Also, you might try the
  2359. hypertext scan to look for "BAS" and " C ".  Grant
  2360. ---------------
  2361. ** Current thread: B-TO-C
  2362.  
  2363. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DW52154 Date: 09/27/89
  2364. From: JOHN LLOYD                                            Time: 05:35 am
  2365.   To: GRANT ELLSWORTH (Rcvd)                                (Read 98 times)
  2366. Subj: R: B-TO-C
  2367.  
  2368. Thanks, I will look for the ones mentioned.  Already did the search,
  2369. without results cept for b-to-c.
  2370. ---------------
  2371. ** Current thread: B-TO-C
  2372.  
  2373. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DWL3286 Date: 09/27/89
  2374. From: GRANT ELLSWORTH (Leader)                              Time: 05:54 pm
  2375.   To: JOHN LLOYD (Rcvd)                                     (Read 96 times)
  2376. Subj: R: B-TO-C
  2377.  
  2378. It's possible that I saw those other BASIC-TO-C translator(s) on another
  2379. BBS ... and recalling that I saw them at all was an archeaological exped-
  2380. ition.  I suggest you try accessing "THE TOOL SHOP" in Phoenix, AZ
  2381. (accisible via PCPURSUIT) at 602-279-2673.  The Tool SHop also has a
  2382. commendable upload set --- not as elaborate or deep as the one here on
  2383. EXECPC, of course, but it has a different focus (C and pgming tools).  Be
  2384. prepared to wait a LONG WAIT on redials to get connected - that bbs is
  2385. real popular out in that part of the West.  Grant
  2386. ---------------
  2387. ** Current thread: B-TO-C
  2388.  
  2389. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DX51891 Date: 09/28/89
  2390. From: JOHN LLOYD                                            Time: 05:31 am
  2391.   To: GRANT ELLSWORTH (Rcvd)                                (Read 93 times)
  2392. Subj: R: B-TO-C
  2393.  
  2394. Thanks again.  I was getting ready to try the New York Board that is the
  2395. home of 'The List', as it is supposed to be a C support system as well.
  2396. If you have a chance to look at the B-to-C in the Mahoney collecting, you
  2397. might find it interesting, and perhaps could shed some light on the
  2398. meaning of the resultant code.   It generates code familiar in structure
  2399. to C, but the functions in the generated code are not standard C.  It
  2400. seems to be needing a library to go with it, or require further
  2401. translation.  I don't know.
  2402. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  2403.  
  2404. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DSB1745 Date: 09/23/89
  2405. From: AMERICA WEST                                          Time: 07:29 am
  2406.   To: ALL                                                   (Read 109 times)
  2407. Subj: PRO-C
  2408.  
  2409. Has anyone out there had any experience with PRO-C from Vestronix?
  2410. We have purchased and are using it to generate C code, we are generating
  2411. applications that have data files compatible with dBase III+ so we are
  2412. using DBCIII+ routines from Lattice.  The code generator seems to
  2413. generate good C code (lots of it!).  I have a lot of experience
  2414. programming in Basic and just a rudimentary knowledge of C.  I can usually
  2415. determine what a C program is doing by reading the source code, but I am
  2416. nowhere near proficient in generating C code.  What have been your
  2417. experiences with this package?  Have there been any major problems with
  2418. the code that it generates?  Any comments would be greatly appreciated.
  2419. Jim Arner
  2420. America West C&E, Inc.
  2421. 311 Washburn Drive
  2422. Rock Springs, WY 82901
  2423. 307-382-5663
  2424. FAX-382-7323
  2425. ---------------
  2426. Following thread
  2427.  
  2428. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DUK1178 Date: 09/25/89
  2429. From: ROBERT BALSOVER                                       Time: 04:19 pm
  2430.   To: AMERICA WEST (Rcvd)                                   (Read 107 times)
  2431. Subj: R: PRO-C
  2432.  
  2433. Jim, I have been considering PRO-C, I'd like to here opinions about it
  2434. and anything anyone else tells you.
  2435. Thanks  Bob
  2436. ---------------
  2437. ** Current thread: PRO-C
  2438.  
  2439. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 323K2077 Date: 02/03/90
  2440. From: DENNIS DODSON                                         Time: 04:34 pm
  2441.   To: JOHN ABATTE (Rcvd)                                    (Read 86 times)
  2442. Subj: PRO-C
  2443.  
  2444. John,
  2445. I'm using Pro-C and if you (S)earch previous messages you`ll see that
  2446. there has been some discussions and queries in the past.  As far as your
  2447. question goes, I think Pro-C is a valuable development tool for new
  2448. applications.  The generated source code is very good and easy to follow
  2449. and most of the time requires few modifications and runs right 'out of the
  2450. shute' to accomplish the programming task.  Of course a source code gerer-
  2451. ator (spelling) will not do everything for you, but it sure makes the
  2452. development time drastically cut.  We paid $499 for the product early in
  2453. 1989, but I've heard that they`re working on a new release, maybe that's
  2454. why the price has dropped.  I don't know what other information to offer
  2455. to you, but if you can give me an idea of your programming requirements
  2456. maybe I can help in your decision.  As far as we're concerned though,
  2457. Pro-C has been a good investment for us and we are anxiously awaiting
  2458. any new releases.
  2459.  
  2460. Dennis
  2461. ---------------
  2462. ** Current thread: PRO-C
  2463.  
  2464. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 324L0447 Date: 02/04/90
  2465. From: JOHN ABATTE                                           Time: 05:07 pm
  2466.   To: DENNIS DODSON (Rcvd)                                  (Read 82 times)
  2467. Subj: PRO-C
  2468.  
  2469.  
  2470. Hi Dennis
  2471.  
  2472.     Thanks for the info regarding Pro-C. I did do a search for previous
  2473. messages on Pro-C, but only came up with 3 messages. My understanding of
  2474. it is that it is primarily for developing database applications. Is this
  2475. accurate, or does it do more than that? I'm also curious about its
  2476. learning curve. Is it fairly easy to use, or does it require a lot of
  2477. effort to learn?
  2478.  
  2479.     I'm planning to make a trip to the local library to see if I can
  2480. locate any magazine reviews of it.
  2481.  
  2482.     Thanks again for the reply. I guess it would be a good idea to call
  2483. them and ask about their upgrade policy if they are planning a new
  2484. release soon.
  2485.  
  2486. John.
  2487. ---------------
  2488. ** Current thread: PRO-C
  2489.  
  2490. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 325K2044 Date: 02/05/90
  2491. From: DENNIS DODSON                                         Time: 04:34 pm
  2492.   To: JOHN ABATTE (Rcvd)                                    (Read 90 times)
  2493. Subj: PRO-C
  2494.  
  2495. John,
  2496.  
  2497.      Yes, Pro-C is only used for generating database applications.  The
  2498. four types of application programs that you can generate are 1) screen
  2499. programs, 2) menu programs, 3) report programs, and 4) batch (file update)
  2500. programs.  Very 'database-like' in the program design phase.If you are
  2501. considering it for any other reason, forget it.  It is not a general
  2502. purpose C code generator.  It is compatible with Quick C, MSC, Turbo C,
  2503. Watcom, and Zortech C compilers.  The file managers supported are C-Isam,
  2504. Btrieve, C-Tree, dBase III+, and sequential ASCII file access.  Has a very
  2505. powerful and rich programmer's toolbox package (again database
  2506. application-
  2507. like).  Lots of windowing routines and even has a on the fly 'help' appli-
  2508. cation that is embedded in your source code that can be developed and
  2509. maintained from the generated .exe file with the choice of your favorite
  2510. text editor.  Very helpful in business applications.
  2511.  
  2512.      I use it primarily here at work for generating applications.  It
  2513. saves
  2514. me 90% of the 'grunt' coding.  Like I said, some programs have to be
  2515. 'tweaked' after source code generation to put all the 'bells and whistles'
  2516. in, but once you learn the source code generated for the 4 types of pro-
  2517. grams, this becomes a somewhat simple and automatic task.  The shell if
  2518. kind of nice.  Lotus type menus with a (C)ompile item that automatically
  2519. allows you to edit, compile/link, and test your program with one keypress.
  2520. Very user friendly with lots of on-line help.
  2521.  
  2522.      I started out with it as a very 'novice' and confused C programmer.
  2523. Have really learned a lot of sophisticated coding techniques and C
  2524. principles from the generated source code.  It is a good learning tool
  2525. for the beginning C programmer.
  2526.  
  2527.      As far as reviews, I seem to remember in a early '89 PC Mag or PC
  2528. Com-
  2529. uting, it was a 'best of class' for program generators.
  2530.  
  2531. Hope this information answers your questions.
  2532.  
  2533. Dennis
  2534. ---------------
  2535. ** Current thread: PRO-C
  2536.  
  2537. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 32BR3540 Date: 02/07/90
  2538. From: JOHN ABATTE                                           Time: 10:59 pm
  2539.   To: DENNIS DODSON (Rcvd)                                  (Read 91 times)
  2540. Subj: PRO-C
  2541.  
  2542.  
  2543. Hi Dennis
  2544.  
  2545.     Thanks again for the feedback on Pro-C. I did some checking locally
  2546. and found a store that is supposedly getting it in a couple of days, so
  2547. I may bug them for a demo to evaluate it firsthand before making a move
  2548. on it. I still need to do a bit more thinking on it. I appreciate your
  2549. help tremendously. Its always good to hear from someone who's used a
  2550. product before jumping in with both feet first (cold-Turkey).
  2551.  
  2552. Muchas Gracias!!                              John.
  2553. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  2554.  
  2555. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DSI2036 Date: 09/23/89
  2556. From: ERIC WILSON                                           Time: 02:33 pm
  2557.   To: ALL                                                   (Read 101 times)
  2558. Subj: FUNCTIONS
  2559.  
  2560.  Does anyone know where I can get some type of sorting and searching
  2561. functions. If there are no functions written a title to a good book that
  2562. discusses this topic would be a great help.
  2563.    Thanx in advance !
  2564. ---------------
  2565. Following thread
  2566.  
  2567. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DSR0425 Date: 09/23/89
  2568. From: GRANT ELLSWORTH (Leader)                              Time: 10:07 pm
  2569.   To: ERIC WILSON (Rcvd)                                    (Read 100 times)
  2570. Subj: R: FUNCTIONS
  2571.  
  2572. Eric, some of the compilers have built-in library functions for searching
  2573. and sorting - e.g. the Turbo C 2.0 compiler has qsort() and bsearch() (a
  2574. binary search routine).  Books on sorting and searhing techniques are also
  2575. available: Knuth, Donald, Sorting and Searching (Art of Programming Vol 3)
  2576. is a classic on the subject.  Also see, The C Toolbox, by William Hunt, or
  2577. Algorithms, by Robert Sedgewick.  Some of the "Advanced C" type books I
  2578. have seen on the shelves of technical book stores also have some sample
  2579. sorting and searching algorithms written in C.  Hope these comments help.
  2580.  
  2581. Grant
  2582. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  2583.  
  2584. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DUP1048 Date: 09/25/89
  2585. From: JODY IRISH 
  2586. Chain->
  2587.                                            Time: 08:17 pm
  2588.   To: ALL                                                   (Read 96 times)
  2589. Subj: TURBO-C CRUIT
  2590.  
  2591. Hello,
  2592.       I have trying to teach myself Turbo-C for the last year or so...
  2593. Would enjoy experiences and converse of others who tried the same.  I
  2594. currently use ver 1.5 and am known for bangin' my forehead on objects,
  2595. from styrofoam insulated walls to concrete blocks, have dented fenders,
  2596. but not engine blocks!  Am willing to share anything I've learned.
  2597. jli
  2598. ---------------
  2599. Following thread
  2600.  
  2601. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DVQ1696 Date: 09/26/89
  2602. From: GRANT ELLSWORTH (Leader)                              Time: 09:28 pm
  2603.   To: JODY IRISH (Rcvd)                                     (Read 95 times)
  2604. Subj: R: TURBO-C CRUIT
  2605.  
  2606. Jody, Like a lot of others here in this topic/conference, I taught myself
  2607. C using Turbo C (and a couple of other compilers a little later).  Maybe
  2608. you should begin by stating what base you were starting from - e.g.:
  2609.  
  2610. 1.  Previous work with which programming tools/languages
  2611. 2.  How long and doing what kind of hobby or pro-programming
  2612.  
  2613. Also, you might want to tell us what you are finding the most confounding
  2614. in learning/using C, Turbo C, etc..
  2615.  
  2616. Somewhere back in Feb/Mar., we had a short discussion going on here about
  2617. the problems of learing C - as a 2nd (or 3rd, etc.) programming language
  2618. vs as the very first programming language.  The consensus seemed to be
  2619. that learning C as the very first programming language was an invitation
  2620. to frustration city.  Some even thought that prior exposure to, if not
  2621. extensive work with, some other compiled block-structured language like
  2622. PASCAL or PL/I (for IBM 370 Mainframers) was highly desirable, if not
  2623. necessary.  One person wrote that he learned C only after some work with
  2624. dBASE III(?) and found it a very frustrating journey --- but he wrote that
  2625. he finally got the hang of it.
  2626.  
  2627. For my part, my programming "mother toungue" is mainframe assembler and C
  2628. was the 1st so-called "Higher Order Language" I took seriously.  However I
  2629. did have some prior exposure to PASCAL and its ancestor, ALGOL 60 -- a
  2630. long time before.    grant
  2631. ---------------
  2632. ** Current thread: TURBO-C CRUIT
  2633.  
  2634. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DVR2726 Date: 09/26/89
  2635. From: JODY IRISH                                            Time: 10:45 pm
  2636.   To: GRANT ELLSWORTH (Rcvd)                                (Read 94 times)
  2637. Subj: R: TURBO-C CRUIT
  2638.  
  2639. Grant,
  2640.        Thanks for a welcome!  I am not a programmer by trade, just
  2641. curiosity.  I learned BASIC waaaaaayyyyyy back in high school, then
  2642. fortran, but forgot most all of it.  Tried to self-teach myself Turbo
  2643. Pascal, but really found myself hosed up with structured programming.
  2644. I didn't understand the concept, but upon reading about Turbo-C while
  2645. watching a self-taught peer of mine (and kinda mentor/tutor), I started
  2646. figuring it out.  What I found most helpful was pull-down menus and being
  2647. able to read the include files, once I learned what they actually were!
  2648.  
  2649. I am going to upload a small password program tonite (soon).  It's one of
  2650. my first lessons in curiosity-killed-the-cat!  At first, it re-wrote the
  2651. boot track of drive c: to the near last track (605 on my st-225), then if
  2652. the correct password given, wrote it back to finish the boot... BUT...
  2653. After performing several lowlevel formats, I scrapped that idea: TOOOOO
  2654. DANGEROUS!!!  So it just leaves you with a red screen.  I am leaving only
  2655. the source code for all to use, free material.  Will this create any
  2656. hassles?  I hope no greedy people try to profit!  I figure it's worth
  2657. about $.25 myself!!!
  2658.  
  2659. Again, thanks for welcoming me, am very interested in C and sharing
  2660. experiences and problems.
  2661. From: Jody L. Irish, I.M. Computing
  2662. ---------------
  2663. ** Current thread: TURBO-C CRUIT
  2664.  
  2665. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DWJ3303 Date: 09/27/89
  2666. From: KEN HOPKINSON                                         Time: 03:55 pm
  2667.   To: JODY IRISH (Rcvd)                                     (Read 98 times)
  2668. Subj: R: TURBO-C CRUIT
  2669.  
  2670. Hi Jody,
  2671.      One program you might want to look at for learning C is CROBOT in the
  2672. mahoney collection. It isn't really that complicated when you look at what
  2673. you can use, but its kind of fun to see how close you can make your robot
  2674. into a thinking machine that'll wipe everyone else out.
  2675.  
  2676. ken
  2677. ---------------
  2678. ** Current thread: TURBO-C CRUIT
  2679.  
  2680. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DWQ2127 Date: 09/27/89
  2681. From: JODY IRISH                                            Time: 09:35 pm
  2682.   To: KEN HOPKINSON (Rcvd)                                  (Read 93 times)
  2683. Subj: R: TURBO-C CRUIT
  2684.  
  2685. Thanks... I'll look for it!
  2686. ---------------
  2687. ** Current thread: TURBO-C CRUIT
  2688.  
  2689. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DWQ2486 Date: 09/27/89
  2690. From: JODY IRISH                                            Time: 09:41 pm
  2691.   To: GRANT ELLSWORTH (Rcvd)                                (Read 93 times)
  2692. Subj: R: TURBO-C CRUIT
  2693.  
  2694. Grant,
  2695.       Thanks...  I did find that I really like the freedom of C.  I had
  2696. been pondering about C++, but may wait 'til I get better at plain ol' C.
  2697. I have found that C really doesn't care what you tell it to do, as long as
  2698. it's spelled right!  That's good, as I rarely write any orthodox code!
  2699.     Last nite I uploaded passwrd.zip... It's not the greatest, hardly!!!
  2700. My next project will probably be windowing or file handling? I dunno??
  2701. jli
  2702. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  2703.  
  2704. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2DVR3589 Date: 09/26/89
  2705. From: JODY IRISH                                            Time: 10:59 pm
  2706.   To: ALL                                                   (Read 93 times)
  2707. Subj: PASSWORD.C
  2708.  
  2709. Hello everybody,
  2710.     You may have already written a better program, but I'm kinda proud of
  2711. this small program, as it's the first one I actually thought of and wrote.
  2712. After many failures and re-tries, I got something to work!!!
  2713.  
  2714.      The file is called PASSWRD.ZIP.  It should be somewhere in Bob's
  2715. collection under programming support or language support???  It was
  2716. written on turbo-c 1.5, but should be easy to convert.  The .EXE file
  2717. should be about 9K or so, it's not resident, and I access it in my
  2718. autoexec.bat on the hard drive.  It's free to all... please don't sell it,
  2719. just pass it around and don't lay claim to it!
  2720.  
  2721.      There is a readme file included in the zip-file to explain further,
  2722. and comments in the source.
  2723.  
  2724. From: Jody L. Irish, I.M. Computing
  2725. ---------------
  2726.  
  2727. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2E3R0616 Date: 10/03/89
  2728. From: STEVEN KRUEGER                                        Time: 10:10 pm
  2729.   To: ALL                                                   (Read 107 times)
  2730. Subj: LOW LEVEL
  2731.  
  2732. Help:  Looking for a good resource (i.e. book, text files) that provides
  2733. information for programing the 80286 and other 16bit stuff (keyboard,
  2734. monitor, memory).  This must be done in assembly and low level, meaning no
  2735. operating system.  We are having alot of trouble finding stuff on all the
  2736. in's and out's.  It's really for a friend, I only like interrupts, so if
  2737. you can please help us out leave me e-mail or call Alan at 421-6782.
  2738. thanks alot, steve.
  2739. ---------------
  2740. Following thread
  2741.  
  2742. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2E412829 Date: 10/04/89
  2743. From: DAVID THOMAS                                          Time: 12:47 am
  2744.   To: STEVEN KRUEGER (Rcvd)                                 (Read 101 times)
  2745. Subj: R: LOW LEVEL
  2746.  
  2747. Steve,
  2748.  
  2749. A bible for low level stuff is the IBM AT Hardware Technical Reference,
  2750. available from IBM over the phone.  This has the original BIOS source,
  2751. describes the bus, ect. It's expensive, but there is a lot of information.
  2752.  Failing that, I think TAB books or SAMS has a title along the liiines of
  2753. "Assembly language programming for the IBM PC" which talks about timers
  2754. and UARTS.   I'd procure data sheets for the devices I was going to
  2755. program (I.E. timer, UART, CRT controller) and try to make sense of the
  2756. hardware.  Also, a company called Annabooks sells a roll your own AT BIOS
  2757. kit, looking at that code can be instructive.  Good luck
  2758.  
  2759. David
  2760. ---------------
  2761. ** Current thread: LOW LEVEL
  2762.  
  2763. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2E4J2206 Date: 10/04/89
  2764. From: KEN HOPKINSON                                         Time: 03:36 pm
  2765.   To: STEVEN KRUEGER (Rcvd)                                 (Read 99 times)
  2766. Subj: R: LOW LEVEL
  2767.  
  2768. Steven,
  2769.      Have you looked at The New Peter Norton's Programmer's Guide To The
  2770. PC and PS/2?
  2771.  
  2772. ken
  2773. ---------------
  2774. ** Current thread: LOW LEVEL
  2775.  
  2776. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2E4K2144 Date: 10/04/89
  2777. From: STEVEN KRUEGER                                        Time: 04:35 pm
  2778.   To: KEN HOPKINSON (Rcvd)                                  (Read 97 times)
  2779. Subj: R: LOW LEVEL
  2780.  
  2781. Ken, know if the pnp guide has the low level stuff, and if so how can I
  2782. get a copy of it. steve
  2783. ---------------
  2784. ** Current thread: LOW LEVEL
  2785.  
  2786. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2E4L1942 Date: 10/04/89
  2787. From: KEN HOPKINSON                                         Time: 05:32 pm
  2788.   To: STEVEN KRUEGER (Rcvd)                                 (Read 99 times)
  2789. Subj: R: LOW LEVEL
  2790.  
  2791. The Peter Norton's Guide covers everything from direct hardware control to
  2792. Rom Bios to Dos Interrupts and lists quirks of various machines that he's
  2793. noted.  You should be able to get it at a local bookstore (I got my copy
  2794. in Ohio so I don't know where you'd go here).  You could also call direct
  2795. (which costs the same as at any bookstore I've seen) at 1-800-638-3030.
  2796.  
  2797. ken
  2798. ---------------
  2799. ** Current thread: LOW LEVEL
  2800.  
  2801. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2E4Q2069 Date: 10/04/89
  2802. From: STEVEN KRUEGER                                        Time: 09:34 pm
  2803.   To: KEN HOPKINSON (Rcvd)                                  (Read 99 times)
  2804. Subj: R: LOW LEVEL
  2805.  
  2806. ken, thanks alot we'll check it out. steve
  2807. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  2808.  
  2809. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2EEJ0966 Date: 10/10/89
  2810. From: GEORGE KOFMAN                                         Time: 03:16 pm
  2811.   To: ALL                                                   (Read 102 times)
  2812. Subj: QC 2.0 QUESTION
  2813.  
  2814. Message CC'd to:
  2815.      ALL
  2816.      GRANT ELLSWORTH
  2817.  
  2818. Hey gang!
  2819. I am sort of new to Quick C, although not new to the art or programming.
  2820.  
  2821. My humbolt question is as follows: I am writing a small
  2822. mortgage/ammortization calculator, and ran into a "stack overflow" within
  2823. Quick C 2.0. I  √recompiled the same program with QCL /F 2000 prog.c
  2824. and the stack did not overflow. How■≥ever, now the program is crashing
  2825. due to some math errors. When compiled with QCL, it does not specify where
  2826. the error has occured.
  2827.  
  2828. Now, for the question: is it possible to increase the stack size in QC
  2829. (NOT QCL)? If so, how do I go about it?
  2830.  
  2831. Thanks in advance.
  2832. GMK.
  2833. ---------------
  2834. Following thread
  2835.  
  2836. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2EEK2626 Date: 10/10/89
  2837. From: MICHAEL MCCLUNE                                       Time: 04:43 pm
  2838.   To: GEORGE KOFMAN (Rcvd)                                  (Read 99 times)
  2839. Subj: R: QC 2.0 QUESTION
  2840.  
  2841. George
  2842. Select the "Options" menu then choose "Make" then "Linker Flags"
  2843. Select "Stack" and enter an amount.
  2844. Your Welcome in advance
  2845. MLM
  2846. ---------------
  2847. ** Current thread: QC 2.0 QUESTION
  2848.  
  2849. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2EFC3003 Date: 10/11/89
  2850. From: GEORGE KOFMAN                                         Time: 08:50 am
  2851.   To: MICHAEL MCCLUNE (Rcvd)                                (Read 103 times)
  2852. Subj: R: QC 2.0 QUESTION
  2853.  
  2854. Michael ---
  2855.  
  2856. I will try it as soon as I logoff Exec.
  2857.  
  2858. Thanks.
  2859. GMK.
  2860. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  2861.  
  2862. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2EFS0108 Date: 10/11/89
  2863. From: STEPHEN ROSSI                                         Time: 11:01 pm
  2864.   To: ALL                                                   (Read 100 times)
  2865. Subj: DYNAMIC C POINTERS
  2866.  
  2867. I am looking for a technique to dynamically configure a pointer to data
  2868. of different but constant types (ie an array of int or an array of
  2869. doubles). If anybody can help I would appreciate it.
  2870.                                         Thanks
  2871.                                         Stephen Rossi
  2872.  
  2873. ---------------
  2874. Following thread
  2875.  
  2876. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2EGM0610 Date: 10/12/89
  2877. From: GRANT ELLSWORTH (Leader)                              Time: 06:10 pm
  2878.   To: STEPHEN ROSSI (Rcvd)                                  (Read 101 times)
  2879. Subj: R: DYNAMIC C POINTERS
  2880.  
  2881. Stephen, use "typecasting" to achieve your objective.  If you can briefly
  2882. state an example of what you'd like to do, maybe we can provide you with a
  2883. good baseline example.  Here's an example of a typecast for a ptr...
  2884.  
  2885.     char * y;  int * z;
  2886.  
  2887.     y = (char *)z;   /* z was "typecast" for copying the ptr */
  2888.  
  2889. Some of the general purpose C books on the bookstore shelves have some
  2890. more sophisticated and useful examples.   Grant
  2891. ---------------
  2892. ** Current thread: DYNAMIC C POINTERS
  2893.  
  2894. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2EGS0426 Date: 10/12/89
  2895. From: STEPHEN ROSSI                                         Time: 11:07 pm
  2896.   To: GRANT ELLSWORTH (Rcvd)                                (Read 98 times)
  2897. Subj: R: DYNAMIC C POINTERS
  2898.  
  2899. The application I am working on are date structures for a signal
  2900. processing program. The data structure I would like to use is a
  2901. data_header structure which would contain applicable info for the actual
  2902. data (ie frequency spacing, units, calibration etc.) Since the  actual data
  2903. could be either int or float or double or struct complex, I would like to
  2904. code a variable in the header that would let modules know the type of data
  2905. the data pointer (which is in the header stucture) is pointing to.
  2906.                                    Thanks for the speedy reply
  2907.                                    Stephen Rossi
  2908. ---------------
  2909. ** Current thread: DYNAMIC C POINTERS
  2910.  
  2911. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2EHA2033 Date: 10/13/89
  2912. From: TOM FRANK                                             Time: 06:33 am
  2913.   To: STEPHEN ROSSI (Rcvd)                                  (Read 106 times)
  2914. Subj: R: DYNAMIC C POINTERS
  2915.  
  2916. Stephen,
  2917.  
  2918. Sounds like your requirement is a perfect usage of the UNION in C. Your
  2919. header would include a type flag and then a pointer to the union. The
  2920. union would be defined as a composite of all the possible types that could
  2921. occur. The union can include all legal data types including structures. I
  2922. use this type of thing in handling various arbitrary items in a program
  2923. which reads Wordperfect 5.0 files - I define a union which can handle any
  2924. WP 5.0 "code" that I want to process. Thus, I have a conviently defined
  2925. method for passing these "code"s to all of my processing routines and I
  2926. can still use strict prototype checking without a million casts.
  2927.  
  2928. If this is unclear, let me know and we can fish up a simple example.
  2929.  
  2930. Tom
  2931. ---------------
  2932. ** Current thread: DYNAMIC C POINTERS
  2933.  
  2934. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2EIF0660 Date: 10/14/89
  2935. From: STEPHEN ROSSI                                         Time: 11:11 am
  2936.   To: TOM FRANK (Rcvd)                                      (Read 99 times)
  2937. Subj: R: DYNAMIC C POINTERS
  2938.  
  2939. I don't understand how the union will help my situation. Perhaps if you
  2940. could give me an example. I have included some code fragments here to
  2941. try to show my delema.
  2942.  
  2943. #define char bytes
  2944. struct d_header
  2945.     {
  2946.         int     status;
  2947.         int     block_size;
  2948.         int     type;
  2949.         int     mode;
  2950.         char    *description;
  2951.         char    *units_x;
  2952.         char    *units_y;
  2953.         float   delta;
  2954.         bytes   *data;         /* This pointer points to a block_size *
  2955.                                   sizeof(actual data) block of data
  2956.                                   where actual data size is of different
  2957.                                   size for each type of data */
  2958.         float   sensitivity;
  2959.     } header_array[MAX_CHANNELS];
  2960.  
  2961.         struct d_header *thrd_octave;
  2962.  
  2963.         thrd_octave = &header_array[c];  /* where c is the channel # */
  2964.         thrd_octave->mode = THRD_OCT;
  2965.         .
  2966.         .
  2967.         .
  2968.         thrd_octave->data = (bytes *)calloc(MAX_BAND_NO,sizeof(*data));
  2969.         .
  2970.         .
  2971.         .
  2972.         thrd_data = (double *)thrd_octave->data; /* Here is where I have
  2973.                                                     my problem. To
  2974.                                                     access the data with
  2975.                                                     a configable pointer
  2976.                                                     according to type */
  2977. I hope this clarifies my situation.
  2978.  
  2979.                                         Stephen Rossi
  2980.  
  2981.  
  2982. ---------------
  2983. ** Current thread: DYNAMIC C POINTERS
  2984.  
  2985. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2EIF2487 Date: 10/14/89
  2986. From: TOM FRANK                                             Time: 11:41 am
  2987.   To: STEPHEN ROSSI (Rcvd)                                  (Read 103 times)
  2988. Subj: R: DYNAMIC C POINTERS
  2989.  
  2990. Stephen,
  2991.  
  2992. When I need to access data of variable types, I use the UNION. A simple
  2993. example would be
  2994.  
  2995.           union d_ptr {
  2996.                char *c_ptr;
  2997.                int *i_ptr;
  2998.                double *d_ptr;
  2999.                } var_ptrs;
  3000.  
  3001. Then depending on the usage in any context you can access var_ptrs.c_ptr
  3002. to use the item as a char pointer, etc. You can also use the -> construct
  3003. if you have a pointer to the union.
  3004.  
  3005. It seems to fit your situation and allows the code to be clear on what is
  3006. happening without a lot of casts.
  3007.  
  3008. NOTE: a union allocates only as much memory as the size of the largest
  3009. item - they all share the same memory area. In the example above, all that
  3010. is allocated is the size of a pointer (in the current memory model).
  3011.  
  3012. Tom
  3013. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  3014.  
  3015. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2EKJ0285 Date: 10/16/89
  3016. From: MASSIMO GENTILINI                                     Time: 03:04 pm
  3017.   To: ALL                                                   (Read 111 times)
  3018. Subj: SEARCH INDEXING LIBRARY
  3019.  
  3020. Anybody knows a GOOD Public Domain or Shareware library for Turbo C 2.0
  3021. to create and access index files???
  3022.  
  3023. Greetings from Italy
  3024. Massimo Gentilini
  3025. Sysop @ 2:332/9
  3026. ps: Please send me also a rpivate answer if you know something
  3027. ---------------
  3028.  
  3029. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2EVN0176 Date: 10/26/89
  3030. From: MICHAEL MCCLUNE                                       Time: 07:02 pm
  3031.   To: ALL                                                   (Read 95 times)
  3032. Subj: TSR ?
  3033.  
  3034. Could someone give me info on writting TSRs in C? Books to read,
  3035. personal experiences, general help on the subject. I am not
  3036. well versed in assembly with only limited experience using
  3037. registers, REGS in <DOS.H>.
  3038. The idea I have would include screen writting and user interaction.
  3039. thanks in advance
  3040. Mike
  3041. ---------------
  3042. Following thread
  3043.  
  3044. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2EVN3404 Date: 10/26/89
  3045. From: KEN HOPKINSON                                         Time: 07:56 pm
  3046.   To: MICHAEL MCCLUNE (Rcvd)                                (Read 89 times)
  3047. Subj: R: TSR ?
  3048.  
  3049. Mike,
  3050.      This is pretty funny as I'm well versed in assembly, but not very
  3051. well at C.  (I kind of want to though, I think I'll take it up this winter
  3052. when things settle down.)  I think I can help you a little with your TSR
  3053. thing though.  The basic idea is that your program attaches itself to
  3054. an interrupt and then takes over whenever that interrupt is called.  What
  3055. you could do is write your program in the normal way, and then make slight
  3056. modifications later to attach itself to the keyboard interrup to search
  3057. for a special key/key sequence and then have itself pop up.  Maybe its
  3058. best if I describe the process of making a TSR terminate and stay
  3059. resident.  First you would change the keyboard interrupt so that it
  3060. pointed to your code.  Then you would design your program so that when a
  3061. key was pressed, your program would first call the old interrupt, then
  3062. look at the pressed key to see if it was what you were looking for, if not
  3063. then send the key to Dos, if it is then you run your program normally from
  3064. there.  But I'm getting ahead of myself.  After you point the interrupt to
  3065. your program, you tell Dos what parts of your program to save and call an
  3066. interrupt to make your program a TSR.  Calling interrupts to make your
  3067. program a TSR and attaching it to the keyboard interrupt could be the only
  3068. time you have to deal with registers hypothetically.  I can't tell you
  3069. what you'd really have to know without knowing more about your program
  3070. (and the C language in general).  I've never read anything about TSR's
  3071. that wasn't in Assembly so I can't help you there.
  3072.  
  3073. ken
  3074. ---------------
  3075. ** Current thread: TSR ?
  3076.  
  3077. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2EWC0580 Date: 10/27/89
  3078. From: STEVEN KEY                                            Time: 08:09 am
  3079.   To: MICHAEL MCCLUNE (Rcvd)                                (Read 92 times)
  3080. Subj: R: TSR ?
  3081.  
  3082. Michael,
  3083.  
  3084. Take a look for a file called TESS-C or something close to that in the
  3085. Mahoney collection.  A group of people have put together routines in C,
  3086. Pascal and assembly for writing TSR's that are well behaved and don't
  3087. trash each other.  There is some tutorial info in the file as well.
  3088.  
  3089. Steven
  3090. ---------------
  3091. ** Current thread: TSR ?
  3092.  
  3093. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2EY12513 Date: 10/29/89
  3094. From: PATRICK MEALEY                                        Time: 12:41 am
  3095.   To: MICHAEL MCCLUNE (Rcvd)                                (Read 88 times)
  3096. Subj: R: TSR ?
  3097.  
  3098. The BEST book I've seen on TSR's in C is "Quick C" by Al Stevens.  It has
  3099. full source code to do just about anything you want in a TSR.  And it
  3100. explains the foibles of the other interrupts.  It's kind of getting old,
  3101. though, and due to the damn IRS publishers are having to shred books which
  3102. aren't on the bestseller list.  You may have trouble finding it.  I saw it
  3103. about 7 months ago, but haven't seen it since.
  3104. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  3105.  
  3106. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2F1E1325 Date: 11/01/89
  3107. From: ED ERDMAN                                             Time: 10:22 am
  3108.   To: ALL                                                   (Read 94 times)
  3109. Subj: EXTENDED KEYBOARD CODES
  3110.  
  3111. As a new C programmer for the purposes of classwork is there any
  3112. relatively simple way of detecting the keypress of the F keys? I realize
  3113. that the obvious way is to use a good windows library; but I am trying to
  3114. learn rather than just "use".
  3115. Thanks in advance,
  3116.                  Ed Erdman
  3117. ---------------
  3118. Following thread
  3119.  
  3120. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2F1J3392 Date: 11/01/89
  3121. From: KEN HOPKINSON                                         Time: 03:56 pm
  3122.   To: ED ERDMAN (Rcvd)                                      (Read 98 times)
  3123. Subj: R: EXTENDED KEYBOARD CODES
  3124.  
  3125. Ed,
  3126.      I'm still an Assembly programmer, but hang out here because C is the
  3127. closest thing to it.  As for an answer, I think that the best way to
  3128. detect F(unction) keys would be to use the Rom Bios.  You would need to
  3129. call interrupt 16h(22 decimal) and use subfunction 0.  Then check the AH
  3130. register for the following values:
  3131. (I'll just give you everything in decimal)
  3132. F1-59
  3133. F2-60
  3134. F3-61
  3135. I just noticed that these numbers just keeping going up through F10 so it
  3136. would be pretty silly to go through them allThat's for a PC type keyboard.
  3137.  On the new 101 key keyboards, there are 12 function keys and the values
  3138. to look for go from 112-123You'd have to know what kind of keyboard it was
  3139. ahead of time to figure it out.  I hope this helps you.  What are you
  3140. working on anyway?
  3141.  
  3142. I guess you could have a prompt asking them in the beginning.
  3143.  
  3144. ken
  3145. ---------------
  3146. ** Current thread: EXTENDED KEYBOARD CODES
  3147.  
  3148. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2F1K3350 Date: 11/01/89
  3149. From: ED ERDMAN                                             Time: 04:55 pm
  3150.   To: KEN HOPKINSON (Rcvd)                                  (Read 100 times)
  3151. Subj: R: EXTENDED KEYBOARD CODES
  3152.  
  3153. Hello Ken,
  3154.      I appreciate your reply. I am not working on anything specific. I am
  3155. an old Mainframe Cobol programmer masochistically trying to learn some new
  3156. tricks. So far I like what I see in "C" , but Some things (like the above)
  3157. I want to know how to do by myself rather than going out and buying
  3158. someone's library. If I was churning some code out for a project I would
  3159. probably use a library (actually I would probably use Cobol as at this
  3160. stage of the game it would see results much faster).
  3161. Again thanks and Best Regards,
  3162.                              Ed Erdman
  3163. ---------------
  3164. ** Current thread: EXTENDED KEYBOARD CODES
  3165.  
  3166. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2F2P1579 Date: 11/02/89
  3167. From: GRANT ELLSWORTH (Leader)                              Time: 08:26 pm
  3168.   To: ED ERDMAN (Rcvd)                                      (Read 98 times)
  3169. Subj: R: EXTENDED KEYBOARD CODES
  3170.  
  3171. Ed, To detect the keyboard scan codes, you can use a "bios_key()" (Turbo
  3172. C) or equivalent function in MSC.  It's from the scan_codes that you
  3173. determine whether you have a function key or something else.  Also, for
  3174. your reference, there are 2 .ZIPs which demonstrate several aspects of
  3175. keyboard access in the Mahoney collection: UNFILKEY.ZIP and GETKBD.ZIP,
  3176. both of which were the results of some misadventures I had in keyboard
  3177. access.  There are at least a couple of others there, but I don't remember
  3178. what their names were.  You might want to do a "Subject" scan in the
  3179. collection for files with keywords like KEYBOARD, CTRL-C, etc..  Often, it
  3180. is problems we are having  with "blocking" the ^C and its siblings which
  3181. leads us into this rather arcane world of keyboard access routines.
  3182.  
  3183. Good hunting!  Grant
  3184. ---------------
  3185. ** Current thread: EXTENDED KEYBOARD CODES
  3186.  
  3187. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2F2P3143 Date: 11/02/89
  3188. From: KEN HOPKINSON                                         Time: 08:52 pm
  3189.   To: ED ERDMAN (Rcvd)                                      (Read 97 times)
  3190. Subj: R: EXTENDED KEYBOARD CODES
  3191.  
  3192. Ed,
  3193.     I like to know how things work myself too.  You should give Assembly a
  3194. try some time. It's very fast and easy to customize to whatever you want
  3195. (using the macro feature, you can create whole libraries of added commands
  3196. if there isn't one there that does what you want).  For now, good luck
  3197. with your C programming.  If you have any more questions just pass them on
  3198. and maybe I'll have the answers to those too.
  3199.  
  3200. ken
  3201. ---------------
  3202. ** Current thread: EXTENDED KEYBOARD CODES
  3203.  
  3204. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2F2P3242 Date: 11/02/89
  3205. From: KEN HOPKINSON                                         Time: 08:54 pm
  3206.   To: GRANT ELLSWORTH (Rcvd)                                (Read 98 times)
  3207. Subj: R: EXTENDED KEYBOARD CODES
  3208.  
  3209. Grant,
  3210.     You can easily block ^C by using Dos function calls.
  3211.  
  3212. ken
  3213. ---------------
  3214. ** Current thread: EXTENDED KEYBOARD CODES
  3215.  
  3216. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2F2S0764 Date: 11/02/89
  3217. From: GRANT ELLSWORTH (Leader)                              Time: 11:12 pm
  3218.   To: KEN HOPKINSON (Rcvd)                                  (Read 97 times)
  3219. Subj: R: EXTENDED KEYBOARD CODES
  3220.  
  3221. Ken, Sorry to report this, but ... with DOS standard function calls you c
  3222. can only partially block the ^C and its friends.  Rather than go into a
  3223. long essay here, I suggest you read some of the remarks in the several
  3224. zips with ^C , ^BRK, etc., keyboard routines.  You might want to start
  3225. with MS's CAROTC.zip.  To illustrate the nuisance of this thing, run you c
  3226. program with the simple dos function calls, then enter ^@, <alt-03>, and
  3227. ^BRK .... if you have trapped all 3 varieties, you should not see a ^C on
  3228. your screen.... but I betcha you'll see it for 1 or more of the above.
  3229.  
  3230. Grant
  3231. ---------------
  3232. ** Current thread: EXTENDED KEYBOARD CODES
  3233.  
  3234. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2F3F0991 Date: 11/03/89
  3235. From: KEN HOPKINSON                                         Time: 11:16 am
  3236.   To: GRANT ELLSWORTH (Rcvd)                                (Read 96 times)
  3237. Subj: R: EXTENDED KEYBOARD CODES
  3238.  
  3239. Grant,
  3240.     Thanks for that piece of knowledge.  I'll look for those files.
  3241.  
  3242. ken
  3243. ---------------
  3244. ** Current thread: EXTENDED KEYBOARD CODES
  3245.  
  3246. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2F3S0394 Date: 11/03/89
  3247. From: ED ERDMAN                                             Time: 11:06 pm
  3248.   To: GRANT ELLSWORTH (Rcvd)                                (Read 95 times)
  3249. Subj: R: EXTENDED KEYBOARD CODES
  3250.  
  3251. Hello Grant,
  3252.      Thanx for your reply.
  3253. Best Regards,
  3254.             Ed Erdman
  3255. ---------------
  3256. ** Current thread: EXTENDED KEYBOARD CODES
  3257.  
  3258. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2F3S0607 Date: 11/03/89
  3259. From: ED ERDMAN                                             Time: 11:10 pm
  3260.   To: KEN HOPKINSON (Rcvd)                                  (Read 97 times)
  3261. Subj: R: EXTENDED KEYBOARD CODES
  3262.  
  3263. Hello Ken,
  3264.     Thanx a lot. I have not taken the time for MASM. I am somewhat
  3265. familiar with mainframe ALC. I hope I will get good enough with C to be
  3266. able to answer someone elses questions sometime. I f I get a chance to
  3267. play with MASM you will probably be hearing from me again.
  3268. Best Regards,
  3269.             Ed Erdman
  3270. ---------------
  3271. ** Current thread: EXTENDED KEYBOARD CODES
  3272.  
  3273. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2FAD1375 Date: 11/06/89
  3274. From: CARL SCHRUBBE                                         Time: 09:22 am
  3275.   To: GRANT ELLSWORTH (Rcvd)                                (Read 93 times)
  3276. Subj: R: EXTENDED KEYBOARD CODES
  3277.  
  3278. There is a good ^C filter under the Mahoney collection. Its loaded
  3279. as a device driver, can be toggled on and off. It's BRK.zip.(?)
  3280.                       CARL
  3281. ---------------
  3282. ** Current thread: EXTENDED KEYBOARD CODES
  3283.  
  3284. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2FC10320 Date: 11/08/89
  3285. From: GRANT ELLSWORTH (Leader)                              Time: 12:05 am
  3286.   To: CARL SCHRUBBE (Rcvd)                                  (Read 94 times)
  3287. Subj: R: EXTENDED KEYBOARD CODES
  3288.  
  3289. Carl, I tried out a BRK varient, if not the thing itself.  That's part of
  3290. what led me to to writing the GETKBD routines which you'll also find in
  3291. the mahoney collection (GETKBD.ZIP).  Also see UNFILKEY.ZIP = another
  3292. approach.  Grant
  3293. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  3294.  
  3295. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2FAD1630 Date: 11/06/89
  3296. From: CARL SCHRUBBE                                         Time: 09:27 am
  3297.   To: ALL                                                   (Read 92 times)
  3298. Subj: _HARDERR HELP
  3299.  
  3300. I am trying to trap the DOS critical error interupt using the Micro 5.1
  3301. _harderr function. Looks good, cant make it work. Does anybody know
  3302. how to use it.
  3303.                          CARL
  3304. ---------------
  3305.  
  3306. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2FBF0400 Date: 11/07/89
  3307. From: ABB INDUSTRIAL                                        Time: 11:06 am
  3308.   To: ALL                                                   (Read 98 times)
  3309. Subj: USING ASSEMBLER ROUTINES WITH LATTICE 3.1
  3310.  
  3311. I am attempting to use one of the C functions in the JazSoft
  3312. library found on this bulletin board.  The routines appear to be
  3313. written for Microsoft C but I am using Lattice C 3.1.  The one
  3314. particular function that I am trying is one that checks a disk
  3315. drive status and returns an int.  The problem that I am having is
  3316. that the function calls two Assembler subroutines and I cannot
  3317. seem to get them to work with the Lattice C.  Maybe someone who
  3318. has worked with Assembler subroutines in Lattice can point me in
  3319. the right direction.
  3320.  
  3321. So far I have tried to simply assemble the two files and link the
  3322. object files with my c object file.  This gave me two unresolved
  3323. externals for the two subroutines.  Then I tried changing the
  3324. calls in my c program to include the '_' before each of the two
  3325. function names.  After linking the newly compiled program with
  3326. the two assembled .obj files I got the following messages:
  3327.  
  3328. Fixup offset exceeds field width near 4657 in TESTC.OBJ(TESTC) offset
  3329. 8B54H
  3330. Fixup offset exceeds field width near 4695 in TESTC.OBJ(TESTC) offset
  3331. 8B5DH
  3332.  
  3333. I really do not know what these messages are trying to tell me
  3334. since I cannot find them in any of my manuals.  I assume they
  3335. mean "do not put the '_' before the function names." The
  3336. statements in the c source to call one of the Assembler routines
  3337. is:
  3338.  
  3339.   weseg = getes();              /* get value of extra segment */
  3340.  
  3341. The Assembler source is as follows:
  3342.  
  3343. Comment *
  3344. ┌────────────────────────────────────────────────────────────────────────┐
  3345. │getes.asm                                                               │
  3346. │Return the Code segment value                                           │
  3347. │                                                                        │
  3348. │Usage:                                                                  │
  3349. │  unsigned int ds;                                                      │
  3350. │                                                                        │
  3351. │  ds = getes();                                                         │
  3352. │                                                                        │
  3353. │ (C) JazSoft Software by Jack A. Zucker (301) 794-5950                  │
  3354. └────────────────────────────────────────────────────────────────────────┘
  3355. *
  3356.  
  3357. title   get es value
  3358. name    getes
  3359.  
  3360.         include dos.mac
  3361.  
  3362.         assume cs:_text
  3363. _text   segment public byte 'code'
  3364.         public _getes
  3365.  
  3366. _getes      proc near
  3367.         mov ax,es
  3368.         ret
  3369. _getes  endp
  3370. _text   ends
  3371.         end
  3372.  
  3373. I put in the "include dos.mac" statement because thats what the Lattice
  3374. manual said to do.  It didn't make a difference.  If anyone can give me
  3375. an idea on how to change the Assembler source to work with Lattice or
  3376. how to call the routine differently in c, your help will be greatly
  3377. appreciated.
  3378.                                        Regards,
  3379.                                             Mark Huff
  3380. ---------------
  3381. Following thread
  3382.  
  3383. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2FBL2928 Date: 11/07/89
  3384. From: KEN HOPKINSON                                         Time: 05:48 pm
  3385.   To: ABB INDUSTRIAL (Rcvd)                                 (Read 90 times)
  3386. Subj: R: USING ASSEMBLER ROUTINES WITH LATTICE 3.1
  3387.  
  3388. I'm an Assembly Language programmer, but I stick to Microsoft so I don't
  3389. know how to help you.  The source code would work normally.
  3390.  
  3391. ken
  3392. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  3393.  
  3394. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2FDN1450 Date: 11/09/89
  3395. From: GREG BARNES                                           Time: 07:24 pm
  3396.   To: ALL                                                   (Read 94 times)
  3397. Subj: TO OS/2 C PROGRAMMERS
  3398.  
  3399. If you are in to OS/2 and C, I'd like to know your name so we can bounce
  3400. questions back and fourth.  I am analyst at Farmland Industries in north
  3401. Kansas City, MO and am actually getting payed to write programs in OS/2.
  3402. What a great job and OS.  If you have any questions about OS/2 I'll try to
  3403. answer then then I can get on the BBS.  I hope some of you can help me
  3404. too.
  3405.                            Thanks, Greg Barnes
  3406. ---------------
  3407. Following thread
  3408.  
  3409. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2FFK1027 Date: 11/11/89
  3410. From: GRANT ELLSWORTH (Leader)                              Time: 04:17 pm
  3411.   To: GREG BARNES (Rcvd)                                    (Read 93 times)
  3412. Subj: R: TO OS/2 C PROGRAMMERS
  3413.  
  3414. Greg, you might also find some OS/2 afficianados in the os/2 conference.
  3415. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  3416.  
  3417. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2FDS2651 Date: 11/09/89
  3418. From: JOE REED                                              Time: 11:44 pm
  3419.   To: GRANT ELLSWORTH (Rcvd)                                (Read 91 times)
  3420. Subj: EXTENDED KEYCOES
  3421.  
  3422. This is another question from the great unwashed who are attempting
  3423. to teach themselves C.
  3424.  
  3425. My question is as follows:  I have written a simple terminal program to
  3426. communicate with a PAD (Packet Assember - Disassembler) which works
  3427. quite well with one (where more than one, but one problem at a time)
  3428. problem.  How can I read extended keycodes from the keyboard.  If
  3429. I scan for a keystroke using:
  3430. if kbhit()!=();
  3431.    c = getch();
  3432.  
  3433. this gets the character to send and I can get it to call function menus
  3434. (CTRL-A or 0x001, and to exit CTRL-Q).  Now it I test the character I
  3435. get from the keyboard to see if it is, say ALT-H, it will, but when
  3436. I return to the main program it sends a ^@ which means I have to
  3437. punch the backspace to clear the character to get the input from the
  3438. receive buffer.  Since this isn't what I wanted or had in mind I thought
  3439. I would ask you for some advice.  Oh yes, I am defining c as a char.
  3440.  
  3441. Thanks in advance,
  3442. Joe Reed
  3443. ---------------
  3444. Following thread
  3445.  
  3446. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2FEN2621 Date: 11/10/89
  3447. From: KEN HOPKINSON                                         Time: 07:43 pm
  3448.   To: JOE REED (Rcvd)                                       (Read 87 times)
  3449. Subj: R: EXTENDED KEYCOES
  3450.  
  3451. If you use dos function call 7 you shouldn't have that problem.
  3452.  
  3453. ken
  3454. ---------------
  3455. ** Current thread: EXTENDED KEYCOES
  3456.  
  3457. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2FFK0725 Date: 11/11/89
  3458. From: GRANT ELLSWORTH (Leader)                              Time: 04:12 pm
  3459.   To: JOE REED (Rcvd)                                       (Read 90 times)
  3460. Subj: R: EXTENDED KEYCOES
  3461.  
  3462. Joe, in general terms, what you need to do is capture both the keycode and
  3463. its scan_code.  Many C compilers have JUST such a function which goes to
  3464. the BIOS directly, not via DOS to fetch the keyboard values.  In TC, the
  3465. function is "bioskey()", in MSC, it's called "_bios_keybrd()" --- this
  3466. function can and should ALSO be used to determine if there is a keystroke
  3467. waiting.  If used to retrieve a keystroke, this function returns an
  3468. integer which includeds the key_code (stnd char id) and the scan_code.
  3469. I'd use this function, rather than go thru the stnd DOS getc() function,
  3470. unless there were a COMPELLING reason to do so.  The fancy jury-rigging
  3471. you'll find in some of the ^BRK, etc., trappers is for those whose code
  3472. needs to stay DOS compatible at that level of action.  Grant
  3473. ---------------
  3474. ** Current thread: EXTENDED KEYCOES
  3475.  
  3476. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2FGD1917 Date: 11/12/89
  3477. From: JOE REED                                              Time: 09:31 am
  3478.   To: GRANT ELLSWORTH (Rcvd)                                (Read 88 times)
  3479. Subj: R: EXTENDED KEYCOES
  3480.  
  3481. Thanks Grant I'll play some with Bioskey() and see what that does for me.
  3482. The description of bioskey() in the Ref guide doesnt tell me that much
  3483. but I'll try again.
  3484. Joe
  3485. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  3486.  
  3487. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2FEE2024 Date: 11/10/89
  3488. From: CREATIVE MARKETING                                    Time: 10:33 am
  3489.   To: ALL                                                   (Read 92 times)
  3490. Subj: INDEXING A FILE
  3491.  
  3492. I am in search of a way to "index" a file using MS Quick C.  I have a file
  3493. that contains 94,000 records and is about 2.5 meg big so I cannot read it
  3494. into an array and hold it for varriable checks.  When I do an 'if' search
  3495. for a match it takes about 30 seconds per 2,000 records to search.  Is
  3496. there a way to index in C? Please help
  3497. Daniel Kram
  3498. Creative Marketing
  3499. ---------------
  3500. Following thread
  3501.  
  3502. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2FFE2957 Date: 11/11/89
  3503. From: JOE VINCENT                                           Time: 10:49 am
  3504.   To: CREATIVE MARKETING (Rcvd)                             (Read 94 times)
  3505. Subj: R: INDEXING A FILE
  3506.  
  3507. >I am in search of a way to "index" a file using MS Quick C.  I have a file
  3508. >that contains 94,000 records and is about 2.5 meg big so I cannot read it
  3509. >into an array and hold it for varriable checks.  When I do an 'if' search
  3510.  
  3511. Well, Mr. Marketing (or may I call you "Creative"), if I were you, I would
  3512. take a look at a commercial-quality file-handling package, such as
  3513. Btrieve.  Btrieve and companion products (such as Xtrieve) are designed to
  3514. do what you want to do.
  3515.  
  3516.      -=≡{JOE}≡=- (tm)
  3517. ---------------
  3518. ** Current thread: INDEXING A FILE
  3519.  
  3520. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2FHC3185 Date: 11/13/89
  3521. From: JOHN HEY                                              Time: 08:53 am
  3522.   To: CREATIVE MARKETING (Rcvd)                             (Read 95 times)
  3523. Subj: R: INDEXING A FILE
  3524.  
  3525. RE: indexing the file
  3526.  
  3527. You might look into the Emerald Bay system, by RSPI.  They are reviewed in
  3528. November 13 issue of INFOWorld.  They provide not only a dBase-type
  3529. language interface to their database format, but they also provide a
  3530. complete C Toolkit for interfacing with the database.  Indexes are
  3531. maintained automatically once they are created.  The system is really
  3532. slick...I am using it to create a sophisticated Medical office management
  3533. package--it is the BEST database management system accessible from C that
  3534. I am aware of.
  3535.  
  3536. Anyway, it can't hurt to call them for info.  The number for RSPI is
  3537. 818-248-0877.
  3538.  
  3539. Good Luck.  John P. Hey (GMT Corp.)
  3540. ---------------
  3541. ** Current thread: INDEXING A FILE
  3542.  
  3543. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2FHE2323 Date: 11/13/89
  3544. From: CREATIVE MARKETING                                    Time: 10:38 am
  3545.   To: JOHN HEY (Rcvd)                                       (Read 96 times)
  3546. Subj: R: INDEXING A FILE
  3547.  
  3548. Thanks John, I am callling them this morning.
  3549. DRK
  3550. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  3551.  
  3552. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2FFN2691 Date: 11/11/89
  3553. From: STEVE LIN                                             Time: 07:44 pm
  3554.   To: ALL                                                   (Read 90 times)
  3555. Subj: WRITING A PROG FOR A BBS
  3556.  
  3557. I'm pretty new to C programming... I got the Turbo C 2.0 language during
  3558. this past summer, but being a student I haven't had much time to explore
  3559. it. Anyway, I'm going to force myself to do so, but now I've hit a small
  3560. thing which I'd like to resolve as painlessly as possible. I'd like to
  3561. find some way of writing (or adding code for) routines to handle I/O
  3562. through the phone lines (ie. BBS) to allow both the remote and local users
  3563. to type at the same time and to, at the same time, monitor the carrier
  3564. signal. Any suggestions?
  3565. ---------------
  3566. Following thread
  3567.  
  3568. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2FGF2395 Date: 11/12/89
  3569. From: KEN HOPKINSON                                         Time: 11:39 am
  3570.   To: STEVE LIN (Rcvd)                                      (Read 91 times)
  3571. Subj: R: WRITING A PROG FOR A BBS
  3572.  
  3573. An Ohioan.  I just left Ohio and ended up here in Wisconsin in June.
  3574. (It's a lot coder up here.  How's everything down there?)  So what you
  3575. want is to have people typing at the same time without getting in each
  3576. others way right?  You could send characters recieved over the phone to
  3577. one window, and chracters typed at the local end to another window.  I
  3578. know of a few programs that wentr this way when they were designing BBS
  3579. software.
  3580.  
  3581. ken
  3582. ---------------
  3583. ** Current thread: WRITING A PROG FOR A BBS
  3584.  
  3585. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2FJ51351 Date: 11/15/89
  3586. From: STEVE LIN                                             Time: 05:22 am
  3587.   To: KEN HOPKINSON (Rcvd)                                  (Read 93 times)
  3588. Subj: R: WRITING A PROG FOR A BBS
  3589.  
  3590. Okay, do you know any routines which do this?
  3591.  
  3592. Everything is fine over here in Ohio. Actually, I'm not a native Ohioan;
  3593. I'm a Marylander, just here for college...
  3594. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  3595.  
  3596. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2FGL1343 Date: 11/12/89
  3597. From: ERIC JABLOW                                           Time: 05:22 pm
  3598.   To: ALL                                                   (Read 89 times)
  3599. Subj: OBFUSCATED CODE
  3600.  
  3601. I have uploaded the file IOCCC89.SHR to the UNIX/Xenix file collection.
  3602. It contains the winners of the 1989 International Obfuscated C Code
  3603. Contest.  The file is in standard SHAR format for UNIX systems, and much
  3604. of the code is UNIX specific.  To look at it on a PC, just remove the
  3605. first character of each line and split the file at the appropriate places.
  3606. On a UNIX or Xenix system, just type the command "sh ioccc89.shr".
  3607. Some of these programs are wicked!
  3608.  
  3609. Eric
  3610. ---------------
  3611.  
  3612. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2FGP3152 Date: 11/12/89
  3613. From: LARRY ASHWORTH                                        Time: 08:52 pm
  3614.   To: HENRIK SCHMIEDICHE (Rcvd)                             (Read 121 times)
  3615. Subj: R: QUICK C 2.0 UPGRADE FOR MSC 5.X USERS
  3616.  
  3617. I'm new to the forum but a friend who works at Novell and I go round and
  3618. round on topics like this one, and It's My Opinion that the bottom line is
  3619. the ability to do what you want.  If you're familiar with a language and
  3620. can get the job done, then that's the point isn't it????  It's easy to
  3621. esoteric about the ULTIMATE LANGUAGE when ultimately the point should be
  3622. productivity.
  3623. And the truth is QuickC is better.
  3624. ---------------
  3625. Following thread
  3626.  
  3627. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2FGQ1844 Date: 11/12/89
  3628. From: HENRIK SCHMIEDICHE                                    Time: 09:30 pm
  3629.   To: LARRY ASHWORTH (Rcvd)                                 (Read 126 times)
  3630. Subj: R: QUICK C 2.0 UPGRADE FOR MSC 5.X USERS
  3631.  
  3632.     LArry,
  3633. if one aonly knows one language and/or onlyhas access to one compiler,
  3634. then clearly one doesn't have a choice. The question is, if one has the
  3635. choice (and ability) what is the best programming language for a task.
  3636. There is no one answer to the question because the definition of "best" is
  3637. in the eye of the beholder. I can write a short database application
  3638. in DBASE III in about 1 tenth the time it takes me to write it in C (or
  3639. less) and if speed is important in defininn what "best" is then I'd be
  3640. stupid to use C. On the other hand if the final product is all that
  3641. matters then C may be a better choice (or may not - depending on
  3642. application). Similar arguments can be made about many other language.
  3643. LISP is clearly better for List Processin then C, while SNOBOL will blow c
  3644. out of the water when it comes to string processing. Ada handels
  3645. multitasking better then C, etc., etc., etc. So before one discusses the
  3646. issue of the best programming language I need to know the application and
  3647. definition of "best". So much for that. As for which version of C is the
  3648. best..... frankly both Quick C and Turbo C are so similar in performance
  3649. and features that It boild sown to a matter of personal preference. I have
  3650. Turbo C. I don't have Quick C. Therefore (suprise) I use and prefer Turboc
  3651. over Quick C. Actaully, what I really want is Quick C++ or Turbo C++.
  3652. Anyone have any idea if Turbo C is being upgraded some time in the future?
  3653.                                            - Henrik
  3654. ---------------
  3655. ** Current thread: QUICK C 2.0 UPGRADE FOR MSC 5.X USERS
  3656.  
  3657. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2FHM3460 Date: 11/13/89
  3658. From: LARRY ASHWORTH                                        Time: 06:57 pm
  3659.   To: HENRIK SCHMIEDICHE (Rcvd)                             (Read 121 times)
  3660. Subj: R: QUICK C 2.0 UPGRADE FOR MSC 5.X USERS
  3661.  
  3662. The truth is that I agree with you 100%.  The work one do tends to focus
  3663. one's attention to the language that best fits the tasks at hand.
  3664.    I write database applications in a Dbase clone compiler, because just
  3665. as you say it makes sense.  I use Quick Basic 4.5 for one page of code
  3666. calculations, and I'm using C for larger jobs.
  3667.    I was reading about the "Ultimate Language" in the message base and
  3668. accidently forwarded my message to you.... As you say I say productivity
  3669. and context sensitivity are the issues not the ultimate compiler...
  3670.    Thank you for the note......
  3671. ---------------
  3672. ** Current thread: QUICK C 2.0 UPGRADE FOR MSC 5.X USERS
  3673.  
  3674. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2FKL2166 Date: 11/16/89
  3675. From: GRANT ELLSWORTH (Leader)                              Time: 05:36 pm
  3676.   To: HENRIK SCHMIEDICHE (Rcvd)                             (Read 114 times)
  3677. Subj: R: QUICK C 2.0 UPGRADE FOR MSC 5.X USERS
  3678.  
  3679. Henrik, i heartily endorse your key points ... especially that which
  3680. went : "... depends on the specific application".  Grant
  3681. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  3682.  
  3683. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2FGP3286 Date: 11/12/89
  3684. From: LARRY ASHWORTH                                        Time: 08:54 pm
  3685.   To: GRANT ELLSWORTH (Rcvd)                                (Read 111 times)
  3686. Subj: R: THE ULTIMATE C COMPILER
  3687.  
  3688. I'm curious what you see in Watcom C when it appears to be so poorly
  3689. supported.  Is it compatible with other libraries??
  3690. ---------------
  3691. Following thread
  3692.  
  3693. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2FKL1800 Date: 11/16/89
  3694. From: GRANT ELLSWORTH (Leader)                              Time: 05:30 pm
  3695.   To: LARRY ASHWORTH (Rcvd)                                 (Read 108 times)
  3696. Subj: R: THE ULTIMATE C COMPILER
  3697.  
  3698. OK, Here's my opinion vs a vs WATCOM C 7.0
  3699.  
  3700. 3 major virtues are:
  3701.  
  3702. o EXCELLENT optimization of object code - lot's of parameter passing
  3703.   via the registers
  3704. o Relatively lower cost than MSC (the other SERIOUS contender, and some-
  3705.   times winner in the optimization sweepstakes)
  3706. o Support for the TINY model --- handy for tight TSR's
  3707.  
  3708. The optimization is so good, that I'd recommend WC as the target com-
  3709. piler for very cpu intensive tasks
  3710.  
  3711. 1 major weakness --- the optimizing pass is slower than MSC by a per-
  3712. ceptable margin.  HOwever, it does produce smaller .exe files - even with
  3713. EXEPACK taken into consideration.
  3714.  
  3715. I have seen ad's for several commercial function libs which DO include
  3716. support for WATCOM C.  And I also note that QD's DesqView provides support
  3717. for WC.
  3718.  
  3719. On the not-so-good side:
  3720.  
  3721. o the editor is rubbish
  3722. o the "express" version (a quick prototyping compiler) which comes with
  3723.   the package is only so-so
  3724. o there have been a few very annoying bugs and getting the fixes is a
  3725.   bit expensive --- unless you live/work in waterloo, ont.
  3726.  
  3727. BTW, the WVIDEO debugger is pretty good -- I like it better than CODEVIEW
  3728. but not nearly as much as the Borland TD product.
  3729.  
  3730. Grant
  3731. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  3732.  
  3733. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2FGQ0061 Date: 11/12/89
  3734. From: LARRY ASHWORTH                                        Time: 09:01 pm
  3735.   To: GREG RYAN (Rcvd)                                      (Read 122 times)
  3736. Subj: R: THE ULTIMATE LANGUAGE
  3737.  
  3738. There seems to be far too many who want to change the rules of the game
  3739. just for the sake of change.  Languages can improve slowly and naturally
  3740. evolve (like C) but we really DON'T need a whole new language.
  3741. Every time you change environment you start from scratch.  Stick with what
  3742. you know unless there isn't any other alternative.  Productivity should be
  3743. the key.
  3744. C library support is what really excites me about C.
  3745. Yes I agree with you, how can we take these bozo's seriously.
  3746. ---------------
  3747. Following thread
  3748.  
  3749. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2FKL2014 Date: 11/16/89
  3750. From: GRANT ELLSWORTH (Leader)                              Time: 05:33 pm
  3751.   To: LARRY ASHWORTH (Rcvd)                                 (Read 118 times)
  3752. Subj: R: THE ULTIMATE LANGUAGE
  3753.  
  3754. >Stick with what you know unless there isn't any other alternative ...
  3755.  
  3756. Good reason for the commercial DP community to hold on to COBOL forever...
  3757. what-ever the cost....
  3758.  
  3759. Technology and techniques change and improve.  We really need to learn how
  3760. to adapt quickly to the new tools of the trade ... else we go the way of
  3761. the blacksmiths.
  3762. ---------------
  3763. ** Current thread: THE ULTIMATE LANGUAGE
  3764.  
  3765. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2FMN0792 Date: 11/18/89
  3766. From: LARRY ASHWORTH                                        Time: 07:13 pm
  3767.   To: GRANT ELLSWORTH (Rcvd)                                (Read 114 times)
  3768. Subj: R: THE ULTIMATE LANGUAGE
  3769.  
  3770. Welll I may have overstated the case and the fact is things are changing
  3771. so fast that you are indeed correct that we need to keep up.
  3772.  But wouldnt you agree that the product is the point and not the compiler.
  3773. I think it's called seeing the forest for the trees.
  3774.  The answer is better programmers, not just better compilers.
  3775. ---------------
  3776. ** Current thread: THE ULTIMATE LANGUAGE
  3777.  
  3778. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2FMQ2932 Date: 11/18/89
  3779. From: LARRY ASHWORTH                                        Time: 09:48 pm
  3780.   To: GRANT ELLSWORTH (Rcvd)                                (Read 111 times)
  3781. Subj: R: THE ULTIMATE LANGUAGE
  3782.  
  3783.  
  3784.   First I'd like to say I've really enjoyed the various ideas presented
  3785. in regards to the "Ultimate" compiler, but what I see as I look at the
  3786. industry is the dynamic change that is creating the ultimate compiler
  3787. release by product release.
  3788.   All compilers seem to be merging, converging, and colescing into a
  3789. common set of environments and capacities.  QuickBasic 4.5 and QuickC 2.0
  3790. are very similar in environment, and QuickBasic is an amazing language
  3791. considering it's Basic roots.
  3792.   The constraints caused by expensive or limited memory have been largely
  3793. eliminated so the door is wide open for explosive growth in all
  3794. directions.
  3795. There really is no reason why Basic couldn't have memory models, or any
  3796. other desirable feature.  There's really no reason for any compiler to
  3797. lack anything of merit.
  3798.   It seems to me that the real question may be more esoteric than a
  3799. discussion of syntax, but rather a question of artificial intelligence.
  3800. Or just intelligence.  What problem are we wanting to solve?  Do we need
  3801. a different tool or a different algorithm.  What influence do the tools
  3802. have on the implementation of the algorithm?
  3803.   Perhaps we should we have a set of languages, that are complementary but
  3804. optimized for a particular type of programming.  Then you have the ability
  3805. to change context smoothly.  With linear syntax.
  3806.   Doesn't C already fit the bill?  With the proper set of libraries you
  3807. can
  3808. do nearly anything you can imagine.   ( Even MORE than I can imagine )  Or
  3809. is C too piecemeal.  A fantastic kludge.  One size fits all.  Sort of.
  3810.   I'd like to hear what you all think is WRONG with current languages.
  3811. Then maybe we could see what the Ultimate Compiler ought to be......
  3812. ---------------
  3813. ** Current thread: THE ULTIMATE LANGUAGE
  3814.  
  3815. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2FMR2832 Date: 11/18/89
  3816. From: GRANT ELLSWORTH (Leader)                              Time: 10:47 pm
  3817.   To: LARRY ASHWORTH (Rcvd)                                 (Read 114 times)
  3818. Subj: R: THE ULTIMATE LANGUAGE
  3819.  
  3820. I think you mean "language" ,,, not "product".  A compiler is merely an
  3821. implementation of a language processor.  And I agree, we need to consider
  3822. the "language" aspect of the tool, not the specific implementation. Yes,
  3823. we DO need better programmers,  and those programmers need good tools.
  3824. ---------------
  3825. ** Current thread: THE ULTIMATE LANGUAGE
  3826.  
  3827. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2FMR3322 Date: 11/18/89
  3828. From: GRANT ELLSWORTH (Leader)                              Time: 10:55 pm
  3829.   To: LARRY ASHWORTH (Rcvd)                                 (Read 111 times)
  3830. Subj: R: THE ULTIMATE LANGUAGE
  3831.  
  3832. Concerning C as already "fitting the bill",  ,,, As much as I like to use
  3833. C, I do find some aspects of its syntax and constructs prone to
  3834. introducing "errors" which can hide from you (consider "if(a=b)" vs
  3835. "if(a==b)" for example).  C sets traps for the unwary coder.  And, as
  3836. such, is a little deficient.  But I do not disparage or denigrate the
  3837. inherent flexibility and extensibility of the language -- in that respect
  3838. it is a good tool.   The ultimate tool???? No.  I doubt there is any one
  3839. language or baseline programming tool which can adequately satisfy the
  3840. needs of all applications,,, and I doubt there is one underlying grammar
  3841. which could cover all the necessary bases.
  3842. ---------------
  3843. ** Current thread: THE ULTIMATE LANGUAGE
  3844.  
  3845. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2FN12438 Date: 11/19/89
  3846. From: JOHN HEIM                                             Time: 01:40 am
  3847.   To: GRANT ELLSWORTH (Rcvd)                                (Read 114 times)
  3848. Subj: R: THE ULTIMATE LANGUAGE
  3849.  
  3850. RE: I doubt ther is one underlying grammer which could cover all the
  3851.      necessary bases.
  3852.  
  3853. Agreed.  But C comes closer than anything else currently in existance.  I
  3854. doubt that any other language has been used for a wider variety of tasks.
  3855. It's become the language of choice for programmers in the micro and mini
  3856. arenas and is making inroads on the bigger machines.  I'm always running
  3857. into mainframe guys who are really interested in learning C.  Quite a job
  3858. for some RPG and COBOL programmers.  I've even had some say they dont see
  3859. what can be so hard about it.  It can't be that different from what
  3860. they're already doing - right?
  3861.  
  3862. John
  3863. ---------------
  3864. ** Current thread: THE ULTIMATE LANGUAGE
  3865.  
  3866. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2FU10694 Date: 11/25/89
  3867. From: GRANT ELLSWORTH (Leader)                              Time: 12:11 am
  3868.   To: JOHN HEIM (Rcvd)                                      (Read 112 times)
  3869. Subj: R: THE ULTIMATE LANGUAGE
  3870.  
  3871. John,  I agree .. C is "closer" than any other commonly used tool
  3872. available today,  but, I've been impressed with the more "consistent"
  3873. syntax of Modula-2, and have been hearing some good comments on ADA.
  3874.  
  3875. Now, on your other topic, if you want to see a mainframe cobol/rpg
  3876. programmer "freak out", submit a large C system source code with a K+R
  3877. and another learing guide in front of victim.  There will be many cries
  3878. of exasperation and horror before comprehension.  The big hurdle for these
  3879. programmers is C's use of pointers.  The 2nd lesser hurdle is C's concept
  3880. of "scope".
  3881.  
  3882. Grant
  3883. ---------------
  3884. ** Current thread: THE ULTIMATE LANGUAGE
  3885.  
  3886. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2FVQ1244 Date: 11/26/89
  3887. From: JOHN HEIM                                             Time: 09:20 pm
  3888.   To: GRANT ELLSWORTH (Rcvd)                                (Read 109 times)
  3889. Subj: R: THE ULTIMATE LANGUAGE
  3890.  
  3891. RE: Mod-2 and ADA.
  3892.  
  3893. I've never used either.  It would be nice though if we could come up with
  3894. a languge with C's good qualities but w/o it's little quirks.  It would be
  3895. easy to imagine a language with better syntax than C.  ie.
  3896.  
  3897.      if (a = b) { ... mess ...}
  3898.  
  3899. (which, of course causes mess to be executed every time) is a mistake I
  3900. continue to make ocassionally and have a hard time finding.
  3901.  
  3902. There are alot of other things in C that can make it easy to make
  3903. mistakes.
  3904.  
  3905. John
  3906. ---------------
  3907. ** Current thread: THE ULTIMATE LANGUAGE
  3908.  
  3909. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2G1C2440 Date: 12/01/89
  3910. From: GREG KOCHANIAK                                        Time: 08:40 am
  3911.   To: JOHN HEIM (Rcvd)                                      (Read 125 times)
  3912. Subj: R: THE ULTIMATE LANGUAGE
  3913.  
  3914. John,
  3915. My way to deal with mess in something like:
  3916.   if (a=b) {... mess ...}
  3917. is my CODE.H include file. It contains definitions like this:
  3918.  
  3919. #define IF(c)          if(c) {
  3920. #define ELSE           ;} else {
  3921. #define ENDIF          ;}
  3922. #define ELSEIF(c)      ;} else if (c) {
  3923.     and more...
  3924. Now after #include <code.h> I can write my program this way:
  3925.  
  3926.     IF (a == b)
  3927.          instructions...
  3928.          instructions...
  3929.     ELSEIF (a == 0)
  3930.          other code...
  3931.     ELSE
  3932.          more code...
  3933.     ENDIF
  3934. and so on. I have more definitions: FOR/ENDF, WHILE/ENDW, CASE/ENDCASE,
  3935. FOREVER/ENDFR and so on. This way the program looks much more clear and is
  3936. easier to analyze. What do you think? If you are interested, I can upload
  3937. my CODE.H here, maybe you will further improve it?
  3938.    Greg
  3939. ---------------
  3940. ** Current thread: THE ULTIMATE LANGUAGE
  3941.  
  3942. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2G5R1173 Date: 12/05/89
  3943. From: JOHN HEIM                                             Time: 10:19 pm
  3944.   To: GREG KOCHANIAK (Rcvd)                                 (Read 100 times)
  3945. Subj: R: THE ULTIMATE LANGUAGE
  3946.  
  3947. RE: code.h
  3948.  
  3949. I'm interested.  I have a few reservations though.  Mainly that the
  3950. uninitiated wouldn't know what to make of the code.  I try keep an open
  3951. mind about such things though.
  3952.  
  3953. John
  3954.  
  3955. PS ---- I set up infinate loops thusly ...
  3956.  
  3957. #define FOREVER ;;
  3958.  
  3959. for (FOREVER)
  3960. {
  3961. ...
  3962. }
  3963.  
  3964. Somehow it seems sorta poetic that C lets you define FOREVER so elegantly.
  3965. ---------------
  3966. ** Current thread: THE ULTIMATE LANGUAGE
  3967.  
  3968. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2GAC0949 Date: 12/06/89
  3969. From: GREG KOCHANIAK                                        Time: 08:15 am
  3970.   To: JOHN HEIM (Rcvd)                                      (Read 102 times)
  3971. Subj: R: THE ULTIMATE LANGUAGE
  3972.  
  3973. John,
  3974. I'll prepare my CODE.H together with an example and ty to UL it here
  3975. with the name like CLEAR_C.ZIP or similar.
  3976.    Greg
  3977. ---------------
  3978. ** Current thread: THE ULTIMATE LANGUAGE
  3979.  
  3980. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2GBA1563 Date: 12/07/89
  3981. From: JOHN HEIM                                             Time: 06:26 am
  3982.   To: GREG KOCHANIAK (Rcvd)                                 (Read 90 times)
  3983. Subj: R: THE ULTIMATE LANGUAGE
  3984.  
  3985. RE: Uploading CODE.H
  3986.  
  3987. Great, leave a message here when it's available and I'll look for it.
  3988.  
  3989. John
  3990. ---------------
  3991. ** Current thread: THE ULTIMATE LANGUAGE
  3992.  
  3993. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2GBE2220 Date: 12/07/89
  3994. From: GREG KOCHANIAK                                        Time: 10:37 am
  3995.   To: JOHN HEIM (Rcvd)                                      (Read 85 times)
  3996. Subj: R: THE ULTIMATE LANGUAGE
  3997.  
  3998. John,
  3999. CLEAR_C.ZIP is available in file section A.
  4000.   Greg
  4001. ---------------
  4002. ** Current thread: THE ULTIMATE LANGUAGE
  4003.  
  4004. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31KP3258 Date: 01/16/90
  4005. From: JOHN HEIM                                             Time: 08:54 pm
  4006.   To: GREG KOCHANIAK (Rcvd)                                 (Read 104 times)
  4007. Subj: R: THE ULTIMATE LANGUAGE
  4008.  
  4009. Greg,
  4010.   Ok, I'll check it out.
  4011. John
  4012. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  4013.  
  4014. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2FJJ2945 Date: 11/15/89
  4015. From: JOE REED                                              Time: 03:49 pm
  4016.   To: GRANT ELLSWORTH (Rcvd)                                (Read 92 times)
  4017. Subj: HELP
  4018.  
  4019. Thanks for the suggestion of using bioskey() rather than getch() as it
  4020. cured the bug I had in the terminal program.
  4021. ---------------
  4022.  
  4023. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2FMH2377 Date: 11/18/89
  4024. From: ED ERDMAN                                             Time: 01:39 pm
  4025.   To: ALL                                                   (Read 98 times)
  4026. Subj: TURBO C VS QUICK C
  4027.  
  4028. I have recently got a copy of Turbo C thru school. I prefer it's compiler
  4029. to that of Quick C but the Editor is absolutely terrible!!! Is there any
  4030. way to install your own editor in the Turbo C environment (like Quick C).
  4031. Lacking that, has anyone heard if Borland is planning to ever upgrade it's
  4032. editor?
  4033. Thanx,
  4034.      Ed Erdman
  4035. ---------------
  4036. Following thread
  4037.  
  4038. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2FMR2635 Date: 11/18/89
  4039. From: GRANT ELLSWORTH (Leader)                              Time: 10:43 pm
  4040.   To: ED ERDMAN (Rcvd)                                      (Read 96 times)
  4041. Subj: R: TURBO C VS QUICK C
  4042.  
  4043. Sorry you find the TC integrated environment editor unsatisfactory.  I
  4044. rather like it (yes, I used old WORDSTAR for a long time, and the TC
  4045. editior uses many of the keystroke patterns).  No, I don't know of any way
  4046. to install your own editor in the TC integrated environment.  But if you
  4047. do have an editor of choice, you could set up some clever .BAT files
  4048. combining use of your editor and the TMAKE program, or the integrated
  4049. environment.
  4050.  
  4051. I tried the QC editor and environment some time ago and found it a little
  4052. confusing and lacking (for my taste, anyway).
  4053. ---------------
  4054. ** Current thread: TURBO C VS QUICK C
  4055.  
  4056. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2FN11674 Date: 11/19/89
  4057. From: JOHN HEIM                                             Time: 01:27 am
  4058.   To: ED ERDMAN (Rcvd)                                      (Read 97 times)
  4059. Subj: R: TURBO C VS QUICK C
  4060.  
  4061. Finally someone who agrees with my opinion of Turbo C's editor.  It
  4062. stinks.  But I doubt there's anything you can do if you want to continue
  4063. in the integrated development environment.  Their docs say they based the
  4064. editor on one of their other products - I forget which one - so I doubt
  4065. they'd redo it.
  4066.  
  4067. John
  4068. ---------------
  4069. ** Current thread: TURBO C VS QUICK C
  4070.  
  4071. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2FPF0528 Date: 11/20/89
  4072. From: ED ERDMAN                                             Time: 11:08 am
  4073.   To: GRANT ELLSWORTH (Rcvd)                                (Read 95 times)
  4074. Subj: R: TURBO C VS QUICK C
  4075.  
  4076. Thanks Grant. I am used to using an editor that has native mouse support.
  4077. If we all liked the same thing where would the authors be?
  4078. Best Regards,
  4079.             Ed Erdman
  4080. ---------------
  4081. ** Current thread: TURBO C VS QUICK C
  4082.  
  4083. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2FPF0958 Date: 11/20/89
  4084. From: ED ERDMAN                                             Time: 11:15 am
  4085.   To: JOHN HEIM (Rcvd)                                      (Read 100 times)
  4086. Subj: R: TURBO C VS QUICK C
  4087.  
  4088. Hello John,
  4089.     I think they probably used the so-called editor that they had in
  4090. Turbo-Pascal release 1.0 (and I dont think they made any changes to it). I
  4091. am already pretty much used to using TCC. I am just in the process of
  4092. learning C so havent done anything large enough to need TMAKE. I think I
  4093. read somewhere that there is a way of accessing Turbo C's help system from
  4094. your own editor, but have not found their help to be of enough help to
  4095. bother.
  4096.     I must admit that i prefer TC,s compile speed and library to those of
  4097. Quick-C. If I ever become a C bigot I will probably get a bigger and
  4098. better compiler from someone else anyway.
  4099. Best Regards,
  4100.             Ed Erdman
  4101. ---------------
  4102. ** Current thread: TURBO C VS QUICK C
  4103.  
  4104. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2FVQ0500 Date: 11/26/89
  4105. From: JOHN HEIM                                             Time: 09:08 pm
  4106.   To: ED ERDMAN (Rcvd)                                      (Read 96 times)
  4107. Subj: R: TURBO C VS QUICK C
  4108.  
  4109. RE: If I ever become a C bigot ...
  4110.  
  4111. You mean you're not already?
  4112.  
  4113. The only 'big' compilers I've used professionally are Lattice and
  4114. Microsoft (and various Unix C compilers).  I was impressed by Lattice but
  4115. that was a few years ago.  Mostly I've used Microsoft on DOS machines and
  4116. I think it's pretty good to although some people I work with hate it.
  4117.  
  4118. Personnally I have 3 compilers, Mark Williams, TurboC and QuickC.  I would
  4119. agree with you're assessment, I like the libraries in TC and the editor in
  4120. QC.  Mark Williams is not bad though.  My version is pretty old and pretty
  4121. primitive by todays standards but it does things that QC and TC still
  4122. dont do.
  4123.  
  4124. John
  4125. ---------------
  4126. ** Current thread: TURBO C VS QUICK C
  4127.  
  4128. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2G5R1610 Date: 12/05/89
  4129. From: ED ERDMAN                                             Time: 10:26 pm
  4130.   To: JOHN HEIM (Rcvd)                                      (Read 82 times)
  4131. Subj: R: TURBO C VS QUICK C
  4132.  
  4133. I am not a C bigot yet, buy I think it is a real possibility. The more I
  4134. learn the better I like it.
  4135. Ed
  4136. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  4137.  
  4138. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2FMR0108 Date: 11/18/89
  4139. From: ED GRIFFIN                                            Time: 10:01 pm
  4140.   To: ALL                                                   (Read 83 times)
  4141. Subj: C GURUS: HELP!
  4142.  
  4143. Please give me the name of the best (ha!) text, text+workbook,
  4144. text+workbook+floppy(ies)(?) for learning Turbo C . And where to buy
  4145. it....(them....)
  4146. I KNOW y'all will all agree on a single text....
  4147.  
  4148. I have mucho mainframe experience in Cobol, SAS, assem, etc....
  4149.  
  4150. Thanks,
  4151.  
  4152. -Ed
  4153. ---------------
  4154. Following thread
  4155.  
  4156. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2FMS0111 Date: 11/18/89
  4157. From: GRANT ELLSWORTH (Leader)                              Time: 11:01 pm
  4158.   To: ED GRIFFIN (Rcvd)                                     (Read 82 times)
  4159. Subj: R: C GURUS: HELP!
  4160.  
  4161. The best book? Hmmm!  There is no "best" from my perspective.   However,
  4162. like you, I was DEEPLY inculcated in big blue programming (mostly ALC)
  4163. before getting anywhere near C.  The book I used and like the best is:
  4164.  
  4165. C Programming Guide, by Jack Purdom, published by QUE.  The book is now
  4166. out in a 2nd addition to cover the "new" ansi conventions.
  4167.  
  4168. No diskettes come with it.
  4169.  
  4170. I also suggest you supplement the Purdom book with latest from K+R.
  4171.  
  4172. Grant
  4173. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  4174.  
  4175. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2FQS0610 Date: 11/21/89
  4176. From: JIM MONROE                                            Time: 11:10 pm
  4177.   To: ALL                                                   (Read 84 times)
  4178. Subj: SCREEN BUFFER
  4179.  
  4180. I am interested in receiving general info on writting through the screen
  4181. buffer, I am relatively new to C programing and this seems like it should
  4182. be a faster way of producing menu screens etc. Any help will be
  4183. appreciated.
  4184. Thank You,
  4185. Jim Monroe
  4186. ---------------
  4187.  
  4188. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2FUH0892 Date: 11/25/89
  4189. From: ROBERT WARREN                                         Time: 01:14 pm
  4190.   To: ALL                                                   (Read 84 times)
  4191. Subj: REDIRECTING OUTPUT - HELP ME.
  4192.  
  4193. Hi.  I'm real new a programming in C.
  4194. I'm using Borland's Turbo C  v 2.01  .  An introductory C book
  4195. had an example that I'm unable to get to work.  Dealing with
  4196. Redirecting Output.    The program follows:
  4197. main()
  4198. {
  4199.     while( getche() !=  'X' )
  4200.        ;
  4201. }
  4202. When this program is run - the text that is typed appears on the Screen,
  4203. until terminated by the letter 'X'.
  4204. According to my introductory C book  -- if I was to execute this
  4205. program from  dos with a  command such as:
  4206.            MYPROG >FILE.TXT
  4207. the information that I type would be redirected to the file - FILE.TXT .
  4208. But this isn't happening for me.
  4209. The information that I type continues to be shown on the screen,
  4210. just as when i executed the program  without the >FILE.TXT
  4211. The file FILE.TXT is created with a zero length, but No text
  4212. is stored in the FILE.TXT file.
  4213. ......................
  4214. Redirection normally works for me, from Dos.
  4215. For Example if i type in   DIR >DIRLIST    the file DIRLIST will contain
  4216. the normal output of the Directory command.
  4217. Any ideas - what I'm doing wrong?
  4218. ---------------
  4219. Following thread
  4220.  
  4221. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2FUI0828 Date: 11/25/89
  4222. From: PAT SHEA                                              Time: 02:13 pm
  4223.   To: ROBERT WARREN (Rcvd)                                  (Read 86 times)
  4224. Subj: R: REDIRECTING OUTPUT - HELP ME.
  4225.  
  4226. rob't :
  4227. 'twould appear that you problem is that you have not told the program to
  4228. truly 'write' anything.  furinstince...  what you are seeing is just your
  4229. machine barphing back at you what you have entered via the keyboard
  4230. because you are using getche() <the 'e' on the end of getch indicates that
  4231. the keyboard input is to echoed - getch() does the same thing but duz NOT
  4232. echo the imput>.  you can't redirect that echo.
  4233.  
  4234. suggest you try something like...
  4235.  
  4236. void main( void )
  4237. {
  4238.    char szBuffer[81];
  4239.    int j;
  4240.  
  4241. /* this will NOT be redirect cuz it's going to stderr */
  4242.    fprintf( stderr, "Tell me what you want to 'redirect' :\n\n" );
  4243.  
  4244. /* this get your line of text */
  4245.    for ( j = 0; j < 80; j++ ) {
  4246.        if (( szBuffer[j] = getche() ) == '\r' ) {
  4247.           break;
  4248.        }
  4249.    }
  4250.  
  4251. /* put on the NULL terminator...  */
  4252.    szBuffer[j];
  4253.  
  4254. /* this line CAN be redirected cuz it goes to stdout */
  4255.    printf( "\n%s\n", szBuffer );
  4256. }
  4257.  
  4258. rather 'written-on-the-fly' but it should run ok - don't forget to
  4259. #include <stdio.h> /* for printf and fprintf */
  4260. #include <conio.h> /* for getche */
  4261.  
  4262. you may also wish to try it with getch() in stead of getche() - compile it
  4263. and see if you redirect as you wish to, now.
  4264.  
  4265. happyhacking,
  4266. pats.
  4267. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  4268.  
  4269. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2FVG1334 Date: 11/26/89
  4270. From: GEORGE HOFFMAN                                        Time: 12:22 pm
  4271.   To: ALL                                                   (Read 99 times)
  4272. Subj: TURBO C / QUICK C
  4273.  
  4274. I have Turbo C professional, brand new,, with turbo debugger.  I am a
  4275. novice C programmer and I think I would do better with Quick C.  DOes
  4276. anybody want to trade?  Pls. leave Email.  Thanks
  4277. ---------------
  4278. Following thread
  4279.  
  4280. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2FVM1828 Date: 11/26/89
  4281. From: GRANT ELLSWORTH (Leader)                              Time: 06:30 pm
  4282.   To: GEORGE HOFFMAN (Rcvd)                                 (Read 99 times)
  4283. Subj: R: TURBO C / QUICK C
  4284.  
  4285. George, WHY do you think QC will serve you better than TC?  Grant
  4286. ---------------
  4287. ** Current thread: TURBO C / QUICK C
  4288.  
  4289. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2FVN1420 Date: 11/26/89
  4290. From: GEORGE HOFFMAN                                        Time: 07:23 pm
  4291.   To: GRANT ELLSWORTH (Rcvd)                                (Read 96 times)
  4292. Subj: R: TURBO C / QUICK C
  4293.  
  4294. I guess because of the advertising I've seen, and that QC has some
  4295. tutorial with it.... gmh
  4296. ---------------
  4297. ** Current thread: TURBO C / QUICK C
  4298.  
  4299. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2FVQ2161 Date: 11/26/89
  4300. From: JOHN HEIM                                             Time: 09:36 pm
  4301.   To: GEORGE HOFFMAN (Rcvd)                                 (Read 96 times)
  4302. Subj: R: TURBO C / QUICK C
  4303.  
  4304. According to the prices listed in an add for Programmers Paradise in
  4305. November issue of Doctor Dobbs Turbo Professional is $175 and QuickC is
  4306. $69.  I've used both and though I can see lots of ways QC would be better
  4307. for a novice, I don't think it's THAT much better.  The trade would cost
  4308. you over $100.
  4309.  
  4310. John
  4311. ---------------
  4312. ** Current thread: TURBO C / QUICK C
  4313.  
  4314. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2FYQ1060 Date: 11/29/89
  4315. From: GRANT ELLSWORTH (Leader)                              Time: 09:17 pm
  4316.   To: GEORGE HOFFMAN (Rcvd)                                 (Read 90 times)
  4317. Subj: R: TURBO C / QUICK C
  4318.  
  4319. FYI ... TC has a good on-line help facility and some good examples as
  4320. well.  I saw the QC "tutorial" and don't regard it as a serious learning
  4321. aid.  Grant
  4322. ---------------
  4323. ** Current thread: TURBO C / QUICK C
  4324.  
  4325. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2FYR0288 Date: 11/29/89
  4326. From: GEORGE HOFFMAN                                        Time: 10:04 pm
  4327.   To: GRANT ELLSWORTH (Rcvd)                                (Read 87 times)
  4328. Subj: R: TURBO C / QUICK C
  4329.  
  4330. ok...thanks.  Now, if I need object modules from Microsoft C to act as
  4331. run-time routines for a higher level package such as ASYST (Data
  4332. Acquisition), are Turbo C object modules link/load compatible with
  4333. Microsoft or Quick C modules???? - geo
  4334. ---------------
  4335. ** Current thread: TURBO C / QUICK C
  4336.  
  4337. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2G1R2240 Date: 12/01/89
  4338. From: GRANT ELLSWORTH (Leader)                              Time: 10:37 pm
  4339.   To: GEORGE HOFFMAN (Rcvd)                                 (Read 105 times)
  4340. Subj: R: TURBO C / QUICK C
  4341.  
  4342. If you DO need MSC library routines, or libs compiled explicitly for use
  4343. with MSC applications, you will need to use MSQC or MSC 5.x.  TC object
  4344. and MSC object code are "loosely" compatible, but, the run_time lib
  4345. routines do not have compatible parameter list parameter order, system
  4346. routine names, etc..  It really depends on the library you want to link
  4347. to and its governing technical constraints.  Grant
  4348. ---------------
  4349. ** Current thread: TURBO C / QUICK C
  4350.  
  4351. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2G2H0720 Date: 12/02/89
  4352. From: GEORGE HOFFMAN                                        Time: 01:12 pm
  4353.   To: GRANT ELLSWORTH (Rcvd)                                (Read 100 times)
  4354. Subj: R: TURBO C / QUICK C
  4355.  
  4356. I need object modules which can be called from a program which expects the
  4357. modules to be MSC object types.
  4358. -- geo.
  4359. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  4360.  
  4361. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2FWB3264 Date: 11/27/89
  4362. From: MIKE KELLER                                           Time: 07:54 am
  4363.   To: ALL                                                   (Read 85 times)
  4364. Subj: HELP STORING RETRIEVING STRUCTS
  4365.  
  4366. I'm just getting my C-Legs and I'd like to know if anyone has a nifty way
  4367. of storing a structure with its members to disk and retrieving it.
  4368. I am using Microsoft Quck C.
  4369.  
  4370. Thanks in advance,
  4371.  
  4372. Mike
  4373. ---------------
  4374. Following thread
  4375.  
  4376. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2FX22882 Date: 11/28/89
  4377. From: PAUL MCKENZIE                                         Time: 02:48 am
  4378.   To: MIKE KELLER                                           (Read 89 times)
  4379. Subj: R: HELP STORING RETRIEVING STRUCTS
  4380.  
  4381. Mike, Here is a sample of how to use file streams to read and write
  4382. structures.
  4383.  
  4384. #include <stdio.h>
  4385.  
  4386. struct mystruct {
  4387.    int x;
  4388.    int y;
  4389.    int z;
  4390.    double a;
  4391.    double b;
  4392.    long c;
  4393. };
  4394.  
  4395. struct mystruct ms = {1, 2, 3, 1.1, 2.2, 1234};
  4396. struct mystruct ms2;
  4397. FILE *infile;
  4398.  
  4399.  
  4400. main()
  4401. {
  4402.   infile = fopen("temp","wb");
  4403.  
  4404.   /* This writes the structure to a file */
  4405.   fwrite(&ms,sizeof(struct mystruct),1,infile);
  4406.   fclose(infile);
  4407.   infile = fopen("temp","rb");
  4408.  
  4409.   /* This reads the structure back into ms2 */
  4410.   fread(&ms2,sizeof(struct mystruct),1,infile);
  4411.   fclose(infile);
  4412.  
  4413.   /* Verify  */
  4414.   printf ("x = %d   y = %d   z = %d\na = %lf    b = %lf\n  c = %u\n",
  4415.            ms2.x, ms2.y, ms2.z, ms2.a, ms2.b, ms2.c);
  4416. }
  4417.  
  4418.  
  4419.                     Hope it helps!
  4420.                                          Paul
  4421. ---------------
  4422. ** Current thread: HELP STORING RETRIEVING STRUCTS
  4423.  
  4424. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2FX43548 Date: 11/28/89
  4425. From: MIKE KELLER                                           Time: 04:59 am
  4426.   To: PAUL MCKENZIE (Rcvd)                                  (Read 84 times)
  4427. Subj: R: HELP STORING RETRIEVING STRUCTS
  4428.  
  4429. Thanks!!!
  4430. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  4431.  
  4432. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2FXQ2371 Date: 11/28/89
  4433. From: DENNIS DODSON                                         Time: 09:39 pm
  4434.   To: ALL                                                   (Read 89 times)
  4435. Subj: PRO-C QUESTIONS
  4436.  
  4437. Hello out there....
  4438. Saw a little commentary on the use and value of Pro-C.  Hope I can help.
  4439. Have been using package now for about 4 months.  Started out a a very
  4440. NON-Proficient C programmer (Still have a long way to go).  Pro-C has been
  4441. a very valuable tool for us to develope NEW applications.  Probably 90% of
  4442. that grunt coding is taken care of on the front-end phase before the
  4443. source code generation - Very Helpful !  Allows more project time to be
  4444. spent on the tweaking and customizing phase vs. the grunt phase.  Source
  4445. code is good (I think), and the more you see of it, the more you will
  4446. learn about the language.  Am presently using with C-Tree isam and
  4447. networked Btrieve file structures.  1 unique key and up to 64 duplicate
  4448. keys are supported (dependent upon file handler used). Main areas of
  4449. program type generated are Menu, Batch, Report, Screens.  Multiple screens
  4450. are supported.  Windowing is available.  Typical add/chg/del/inq screen
  4451. with 58 fields and 3 screens was developed in 1/2 day, compile, tested,
  4452. and source code frozen for customizing by days end.  Tell me how long that
  4453. would take if you wrote from scratch ?  Toolkit that comes with package is
  4454. excellent.  Company is in Canada, support is fantastic, they don't even
  4455. ask who's calling.  If I can help anyone, please let me know.
  4456.  ---Dennis
  4457. ---------------
  4458. Following thread
  4459.  
  4460. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2GDP2407 Date: 12/09/89
  4461. From: DAVID FENSKE                                          Time: 08:40 pm
  4462.   To: DENNIS DODSON (Rcvd)                                  (Read 67 times)
  4463. Subj: R: PRO-C QUESTIONS
  4464.  
  4465. I knew I should look in more more often.  I also use Pro-C, bu normally in
  4466. the Xenix environment.  (The product runs on DOS, Xenix and QNX)
  4467.  
  4468. I've got 3 fresh DOS copies of Pro-C.  If anyone is interested in the
  4469. product, I'd be willing to come up with a good price.  After all, isn't
  4470. this just the sort of thing you'd like to get for Christmas??
  4471.  
  4472. If you'd like more info, just leave e-mail.
  4473.  
  4474. DF
  4475. ---------------
  4476. ** Current thread: PRO-C QUESTIONS
  4477.  
  4478. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2GEK1783 Date: 12/10/89
  4479. From: DENNIS DODSON                                         Time: 04:29 pm
  4480.   To: DAVID FENSKE (Rcvd)                                   (Read 72 times)
  4481. Subj: R: PRO-C QUESTIONS
  4482.  
  4483. Gee Dave, Thanks for the offer, but our site license is fine for now.
  4484. Too bad that we're not using the same OS, it would be nice to compare
  4485. notes and problems with someone.  Am currently migrating from the single
  4486. user Btrieve to Novell networked and am experiencing some problems with
  4487. test of programs that worked o.k. single-user.  Looks like will have to
  4488. modify the io4.c module somewhat for record/file locking and add some code
  4489. to generated programs to work around this.  Pro-C says that the Novell
  4490. version is not tested and that is a future project, and they have no
  4491. facilities at this time to test (i.e., no network, tsk,tsk).  Also are
  4492. coming out with an feature enhanced product in 1st quarter.  Will be
  4493. looking for that one.  Well, have to go now, depressed because of Packers
  4494. today.  If you do have any more on Pro-C, please leave a message.
  4495. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  4496.  
  4497. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2G3S1476 Date: 12/03/89
  4498. From: ERIC JABLOW                                           Time: 11:24 pm
  4499.   To: ALL                                                   (Read 85 times)
  4500. Subj: HEX, OCTAL, AND ANSI
  4501.  
  4502. Traditionally, the only alternative base for constants in C was octal.
  4503. C was invented by Kernighan @ Ritchie to run on DEC PDP-11s, and octal was
  4504. the natural base for machine language on them.  PDP-11 words have 12 bits,
  4505. split into 4 octal digits,.  Because of this, the original language
  4506. allowed the octal notation.  For PCs, hexadecimal notation is more
  4507. natural, and so a hex extension was added in ANSI C.  The important fact
  4508. is that some supposedly ANSI-conformant C compilers mishandle octal
  4509. constants; the behavior of string expressions like "\177364" can be a bit
  4510. fuzzy.  In old K&R C, this would be the octal byte \177 followed by
  4511. the characters 7, 3, 6, 4, and a null byte.  Now, it may be the number
  4512. 177364 octal, or it may not.  Hexadecimal notation causes fewer problems.
  4513. The ANSI way to mix octal constants with digits in strings that is
  4514. guaranteed to work even on defective compilers is that of using string
  4515. concatenation.  Try "\177" "364".
  4516. ---------------
  4517.  
  4518. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2G4Q2459 Date: 12/04/89
  4519. From: RICHARD PATRICK                                       Time: 09:40 pm
  4520.   To: ALL                                                   (Read 81 times)
  4521. Subj: FAX TRANSMISSION
  4522.  
  4523. We are developing a Program that needs to send a short ASCII message
  4524. through a modem to a Fax Machine. The program is being writen in Clipper.
  4525. If you know a routine or other product that will do this, please leave a
  4526. message. Thanks.
  4527. ---------------
  4528.  
  4529. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2GEJ1978 Date: 12/10/89
  4530. From: ANDY VESEL                                            Time: 03:32 pm
  4531.   To: ALL                                                   (Read 62 times)
  4532. Subj: COMPLEX ARITHMETIC
  4533.  
  4534. Does anyone know where I can get a math library for C which includes
  4535. Complex Arithmetic?
  4536. Thanks in advance for your help.
  4537. Andy
  4538. ---------------
  4539.  
  4540. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2GHH3583 Date: 12/13/89
  4541. From: ABB INDUSTRIAL                                        Time: 01:59 pm
  4542.   To: ALL                                                   (Read 73 times)
  4543. Subj: C PROGRAMMING FOR APPLES AND MACS
  4544.  
  4545. I am not very familiar with either Apples or Macs at this point in
  4546. time, and I have a few questions about them.  I have written a few C
  4547. programs for IBM compatible systems and I am toying with the idea of
  4548. transporting them to the Apple/Mac world.  If anyone can contribute
  4549. any facts, possibilities, or personal opinions on any of the following
  4550. questions I will appreciate it.
  4551.  
  4552. 1.  Does the MacIntosh have the ability to run software programs that
  4553.     were written to run on Apple IIs?
  4554.  
  4555. 2.  Does anyone know of a C compiler for any of the Apple II
  4556.     computers?  If so, what hardware is required (II/c/e/GS)?
  4557.  
  4558. 3.  Has anyone had any experience with THINK C for the Mac?  How does
  4559.     it compare to programming with Microsoft C 5.1?
  4560.  
  4561. 4.  Are there any other Mac C compilers available?
  4562.  
  4563. 5.  I know that there are option boards available for the Mac that
  4564.     will allow the user to run DOS programs on that machine.  Are
  4565.     these common or are they rare in actual usage in the 'real world'?
  4566.  
  4567. 6.  The programs I have written for IBM systems are mainly text-based
  4568.     with some windows for pop-up menus and data-entry screens.  Does
  4569.     anyone who has ever taken IBM C programs and converted them to the
  4570.     Apple world have any words of warning or advice?
  4571.  
  4572. 7.  Does anyone know of any good books on these subjects that might
  4573.     help me in my endeavors?
  4574.  
  4575. Thanks in advance for any help that you can provide.
  4576.  
  4577.                                         Regards,
  4578.                                             Mark Huff
  4579. ---------------
  4580. Following thread
  4581.  
  4582. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2GIC1216 Date: 12/14/89
  4583. From: STEVEN KEY                                            Time: 08:20 am
  4584.   To: ABB INDUSTRIAL (Rcvd)                                 (Read 72 times)
  4585. Subj: R: C PROGRAMMING FOR APPLES AND MACS
  4586.  
  4587. Mark,
  4588.  
  4589. I can't answer most of your questions, since I don't C.  I can tell you
  4590. that the Apple II is a very different kind of machine from the MAC.  The
  4591. II is not so terribly different from the PC in a lot of ways - they are
  4592. both command driven machines, text driven.  The MAC is another world.
  4593. There is a big cliff at the beginning of the learning curve that you must
  4594. climb up to write your first "hello world" program.  You have to learn the
  4595. windows, dialog boxes, etc.
  4596.  
  4597. There are only a few commercial programs with versions for both the MAC
  4598. and the PC.  I don't think there is anything that adds the II to the list.
  4599.  
  4600. Steven
  4601. ---------------
  4602. ** Current thread: C PROGRAMMING FOR APPLES AND MACS
  4603.  
  4604. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2GIC2090 Date: 12/14/89
  4605. From: ABB INDUSTRIAL                                        Time: 08:34 am
  4606.   To: STEVEN KEY (Rcvd)                                     (Read 68 times)
  4607. Subj: R: C PROGRAMMING FOR APPLES AND MACS
  4608.  
  4609. Steven,
  4610.  
  4611.    Thanks for your input.  I guess I'll have to take on these two new
  4612. environments one at a time if I decide to try it at all.  From the sounds
  4613. of it the Apple II line sounds like an easier transition to me.  Thanks
  4614. again.
  4615.                                     Regards,
  4616.                                          Mark
  4617. ---------------
  4618. ** Current thread: C PROGRAMMING FOR APPLES AND MACS
  4619.  
  4620. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2GIS0490 Date: 12/14/89
  4621. From: GRANT ELLSWORTH (Leader)                              Time: 11:08 pm
  4622.   To: ABB INDUSTRIAL (Rcvd)                                 (Read 67 times)
  4623. Subj: R: C PROGRAMMING FOR APPLES AND MACS
  4624.  
  4625. Mark, it might help to know that there are PASCAL implementations for both
  4626. the MAC and the Apple IIe/II-GS.  Borland's Pascal is one of the
  4627. implementations available for the MAC.  There are also C implementations
  4628. for the MAC --- including, but not limited to, one from Apple.  While  I'm
  4629. not super certain, I believe I've read about a C compiler for the Apple II
  4630. series as well.  Grant
  4631. ---------------
  4632. ** Current thread: C PROGRAMMING FOR APPLES AND MACS
  4633.  
  4634. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2GJC1210 Date: 12/15/89
  4635. From: ABB INDUSTRIAL                                        Time: 08:20 am
  4636.   To: GRANT ELLSWORTH (Rcvd)                                (Read 73 times)
  4637. Subj: R: C PROGRAMMING FOR APPLES AND MACS
  4638.  
  4639. Grant,
  4640.     Thanks for the reply.  From the sounds of it, the Apple II series
  4641. would be easier to transport IBM DOS C programs to when compared to the
  4642. Mac which replies so heavily on the graphics interface.  However, both
  4643. might be fun learning experiences in the future.  I guess I'll have to
  4644. wander down to my local Apple dealer to find a knowledgeable salesperson
  4645. (uncertain smug look) who can tell me if there is such a compiler.
  4646.                                     Regards,
  4647.                                         Mark
  4648. ---------------
  4649. ** Current thread: C PROGRAMMING FOR APPLES AND MACS
  4650.  
  4651. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2GPH0523 Date: 12/20/89
  4652. From: JEFF PARNAU                                           Time: 01:08 pm
  4653.   To: ABB INDUSTRIAL (Rcvd)                                 (Read 74 times)
  4654. Subj: R: C PROGRAMMING FOR APPLES AND MACS
  4655.  
  4656. Symantec's THINK C or Lightspeed C is the best C compiler for MACs, but
  4657. the learning curve is steep and the LSC debugger won't run in less than 2
  4658. meg of RAM (although the compiler and linker will). I am surprised that
  4659. there is no source code for the MAC in the MAC file section of this huge
  4660. BBS. (I couldn't find any C code there.)
  4661. ---------------
  4662. ** Current thread: C PROGRAMMING FOR APPLES AND MACS
  4663.  
  4664. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2GQG1440 Date: 12/21/89
  4665. From: ABB INDUSTRIAL                                        Time: 12:24 pm
  4666.   To: JEFF PARNAU (Rcvd)                                    (Read 78 times)
  4667. Subj: R: C PROGRAMMING FOR APPLES AND MACS
  4668.  
  4669. Jeff,
  4670.    Thanks for the information regarding Mac C compilers.  I am getting the
  4671. impression that there are not too many people who program in C for the
  4672. Macs that frequent this board.  I guess it is still a relatively new
  4673. environment.
  4674.                                   Regards,
  4675.                                        Mark
  4676. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  4677.  
  4678. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2GHL3438 Date: 12/13/89
  4679. From: JONCARL MITCHELL                                      Time: 05:57 pm
  4680.   To: ALL                                                   (Read 73 times)
  4681. Subj: MEMORY
  4682.  
  4683. I am a novice to "C" and Assembly . What I need is a program that can list
  4684. a computers avaliable.when ran from with in a batch file. And the will
  4685. write the memory to a ascii text file of any name.I am a Clipper
  4686. programmer and I need to find how much avaliable memory is avaliable
  4687. before going into my application. I have "C" 5.1 and Microsoft Assembly
  4688. but I'm not a Assembly programmer .Could some one please help me right
  4689. this program.
  4690. JOncarl
  4691. ---------------
  4692.  
  4693. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2GIR1870 Date: 12/14/89
  4694. From: ED ERDMAN                                             Time: 10:31 pm
  4695.   To: GRANT ELLSWORTH (Rcvd)                                (Read 64 times)
  4696. Subj: WHY 03/89
  4697.  
  4698. Hello Grant,
  4699.     How come all of a sudden I am back at 03/24/89 when I request "N"
  4700. messages. I was right up to date with the latest December stuff.
  4701. Best Regards,
  4702.             Ed Erdman
  4703. ---------------
  4704. Following thread
  4705.  
  4706. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2GIS0131 Date: 12/14/89
  4707. From: GRANT ELLSWORTH (Leader)                              Time: 11:02 pm
  4708.   To: ED ERDMAN (Rcvd)                                      (Read 62 times)
  4709. Subj: R: WHY 03/89
  4710.  
  4711. Ed , the same thing happened to me yesterday ... I suspect there's a spook
  4712. in EXECPC software which went out and unset the "push high" date
  4713. associated with our user id's in this topic/conference.  Leave bob m. a
  4714. message in comment at logoff to indicate this behavior may not have bbeen
  4715. limited to one user in one conference.  Since he did maintenance today,
  4716. the problem may have been fixed.  Grant
  4717. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  4718.  
  4719. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2GJP0931 Date: 12/15/89
  4720. From: BILL HOLLS                                            Time: 08:15 pm
  4721.   To: ALL                                                   (Read 86 times)
  4722. Subj: LEARNING C
  4723.  
  4724. I am beginning to learn c with limited programming experience in basic and
  4725. would be interested in suggestions for tutoring programs, library files,
  4726. good sample programs, etc.  I just unwrapped the quick c shrinkwrap.
  4727. thanks
  4728. ---------------
  4729. Following thread
  4730.  
  4731. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2GLN0077 Date: 12/17/89
  4732. From: MICHAEL MCCLUNE                                       Time: 07:01 pm
  4733.   To: BILL HOLLS (Rcvd)                                     (Read 88 times)
  4734. Subj: R: LEARNING C
  4735.  
  4736. Bill
  4737. QC has many example programs in the book "C for yourself which
  4738. are also on the disks that came with QC. Another excellent book
  4739. that is clearly written and easy to understand is The Waite Groups
  4740. Microsoft C... Programming for the PC ISBN# 0-672-22661-8 the
  4741. author of which is Robert Lafore.
  4742. You may also post your question here. There are many C programmers
  4743. eager to help. I cannot help you with any tutorial C programs, I
  4744. have not used any myself.
  4745. Mike
  4746. ---------------
  4747. ** Current thread: LEARNING C
  4748.  
  4749. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2GMB1075 Date: 12/18/89
  4750. From: BILL HOLLS                                            Time: 07:17 am
  4751.   To: MICHAEL MCCLUNE (Rcvd)                                (Read 90 times)
  4752. Subj: R: LEARNING C
  4753.  
  4754. Thanks appreciate your help
  4755. ---------------
  4756. ** Current thread: LEARNING C
  4757.  
  4758. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2GS10721 Date: 12/23/89
  4759. From: JODY IRISH                                            Time: 12:12 am
  4760.   To: BILL HOLLS (Rcvd)                                     (Read 86 times)
  4761. Subj: R: LEARNING C
  4762.  
  4763. Bill,
  4764.      Unfortunately, I'm not a frequent user on this conference, but the
  4765. topic leader is very helpful!  There are others here that are the same!
  4766.  
  4767. What pkg do you have?  I use turbo c, a friend uses Microsoft's Quick C,
  4768. and a few accomplices use others.  I did find some tutors in Mahoney's
  4769. file collection.  The turbo c tutor is titled "tctutor.zip".
  4770.  
  4771. Best bet in the file collection is to scan for "tutor" and the pkg name.
  4772.  
  4773. Hope it helps...
  4774. JL Irish
  4775. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  4776.  
  4777. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2GLS1532 Date: 12/17/89
  4778. From: ERIK DUFEK                                            Time: 11:25 pm
  4779.   To: ALL                                                   (Read 71 times)
  4780. Subj: EXEC PARTY
  4781.  
  4782. I'm interested in organizing an EXEC-PC gathering.  What I have
  4783. in mind is an outing to the casino in Brookfield.  If we get a
  4784. minimum number of people we can have the casino all to ourselves.
  4785. If we can't get a minimum, we'll have to share the facilities
  4786. with others.  The casino offers a bar and a seperate meeting
  4787. room off the main area that could be used as we wish.
  4788.  
  4789. The casino has blackjack, roulette, craps and poker.  You
  4790. start out the evening with $1000 in monopoly money.  At the
  4791. end of the evening any money you have left over can be used
  4792. if you go back some other time.  I don't know if we could use
  4793. the winnings to award door prizes.
  4794.  
  4795. If we want food, there are several catering outfits which the
  4796. casino works with.  I don't have specifics on prices, but the cost
  4797. for the casino only would be around $15 and a buffet $5.
  4798.  
  4799. I'm thinking of scheduling this for the third or fourth week in
  4800. March.  The winter doldrums will probably have set in, and even
  4801. if it's not Vegas, it's cheaper and just as much fun.
  4802.  
  4803. So my question is, is there interest in holding a gathering and
  4804. does this sound like a good place to hold one?  I don't want to
  4805. do any ground work if there's no interest; and if I place my name
  4806. on a contract I sure don't want to pull money out of my own pocket.
  4807.  
  4808. Please leave public replies to this message in Bullroar as I don't
  4809. want to be accused of cluttering up the topic areas.  Or you can
  4810. leave private messages in this topic.  The message in Bullroar
  4811. will have the same heading as this one -- EXEC PARTY.
  4812. ---------------
  4813.  
  4814. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2GSI3250 Date: 12/23/89
  4815. From: ROBERT LUNDAHL                                        Time: 02:54 pm
  4816.   To: ALL                                                   (Read 81 times)
  4817. Subj: ZORTECH C++
  4818.  
  4819. I am trying to use the flash graphics on Zortech C++ 2.0. I was
  4820. wondering if anyone else has had trouble with the flash graphics package.
  4821. ---------------
  4822.  
  4823. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2GTN1245 Date: 12/24/89
  4824. From: PAT SHEA                                              Time: 07:20 pm
  4825.   To: ALL                                                   (Read 83 times)
  4826. Subj: ETC
  4827.  
  4828. <from Gerhard Barth's TAMIAMI bbs - Naples, FL>
  4829.  
  4830.     TWAS THE NIGHT BEFORE IMPLEMENTATION
  4831.  
  4832. 'Twas the night before implementation
  4833. and all through the house,
  4834. not a program was working,
  4835. not even a browse.
  4836.  
  4837. The programmers hung by their tubes in despair
  4838. with hopes that a miracle soon would be there.
  4839. And the users were nestled all snug in their beds,
  4840. while visions of inquiries danced in their heads.
  4841.  
  4842. Then out in the hall there arose such a clatter!
  4843. I sprang from my desk to see what was the matter!
  4844. And what to my wondering eyes should appear,
  4845. but a Super-Programmer (with two six-packs of beer)!
  4846.  
  4847. His resume' glowed with experience so rare,
  4848. he turned out great code with a bit-pusher's flare.
  4849. More rapid than eagles, his programs they came
  4850. and he whistled and shouted and called them by name;
  4851.  
  4852. On update! On add! On inquiry! On delete!
  4853. On batch jobs! On closing! On functions complete!
  4854.  
  4855. His eyes were glazed over, fingers nimble and lean
  4856. from weekends and nights in front of the screen!
  4857. A wink of his eye and a twist of his head
  4858. soon gave me to know I had nothing to dread.
  4859.  
  4860. He spoke not a word, but went straight to his work
  4861. turning specs into code, then turned with a jerk,
  4862. and laying his finger upon the 'enter' key
  4863. the system came up and worked perfectly!
  4864.  
  4865. The updates updated; the deletes, they deleted;
  4866. the inquiries inquired; and closing completed.
  4867. He tested each whistle, and tested each bell
  4868. with nary a bend, and all had gone well.
  4869.  
  4870. The system was finished, the tests were concluded;
  4871. the clients' last changes were even included.
  4872. And the client exclaimed with a snarl and a taunt
  4873. "It's just what I asked for, but not what I want!"
  4874.  
  4875.                 Author Unknown
  4876. ---------------
  4877. Following thread
  4878.  
  4879. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2GVQ1871 Date: 12/26/89
  4880. From: GRANT ELLSWORTH (Leader)                              Time: 09:31 pm
  4881.   To: PAT SHEA (Rcvd)                                       (Read 76 times)
  4882. Subj: R: ETC
  4883.  
  4884. Thanks, Pat. ... Now find and upload that famous old "Programmyr's Tayle"
  4885. ... and maybe then we can know what happened when "grete core y-dumped"!
  4886. Have a happy holiday season!  Grant
  4887. ---------------
  4888. ** Current thread: ETC
  4889.  
  4890. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2GWQ2024 Date: 12/27/89
  4891. From: PAT SHEA                                              Time: 09:33 pm
  4892.   To: GRANT ELLSWORTH (Rcvd)                                (Read 77 times)
  4893. Subj: R: ETC
  4894.  
  4895. ya' know, grant :
  4896.  
  4897. there are rumors about that "the night before..." was written 'bout the
  4898. legendary joe vincent.  that man (i'm told) could boot up a cinder block!
  4899.  
  4900. best regards,
  4901. pats.
  4902. ---------------
  4903. ** Current thread: ETC
  4904.  
  4905. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2GWS2894 Date: 12/27/89
  4906. From: GRANT ELLSWORTH (Leader)                              Time: 11:48 pm
  4907.   To: PAT SHEA (Rcvd)                                       (Read 72 times)
  4908. Subj: R: ETC
  4909.  
  4910. ... I think Joe is into cinder block investments now that he's firmly
  4911. established that he can boot them ...
  4912.  
  4913. Find "The Programmyr's Tale" ... I think Joe and others could really relae
  4914. to it!  Grant
  4915. ---------------
  4916. ** Current thread: ETC
  4917.  
  4918. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2GX41814 Date: 12/28/89
  4919. From: PAT SHEA                                              Time: 04:30 am
  4920.   To: GRANT ELLSWORTH (Rcvd)                                (Read 71 times)
  4921. Subj: R: ETC
  4922.  
  4923. grant:
  4924. 'not familiar w/ 'The Programmyr's Tale' - lemme sniff around and see if i
  4925. can find it.
  4926. best regards, etc.
  4927. pats.
  4928. ---------------
  4929. ** Current thread: ETC
  4930.  
  4931. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2GXL2456 Date: 12/28/89
  4932. From: JOE VINCENT                                           Time: 05:40 pm
  4933.   To: PAT SHEA (Rcvd)                                       (Read 76 times)
  4934. Subj: R: ETC
  4935.  
  4936. >there are rumors about that "the night before..." was written 'bout the
  4937. >legendary joe vincent.  that man (i'm told) could boot up a cinder block!
  4938.  
  4939. Gosh, Pat, what brought that on?
  4940.  
  4941. BTW, next Christmas, may I send all of my messages to you and have you
  4942. <S>end them from Bethlehem?  Happy holidays!  Long time, no telecommuni-
  4943. cate.
  4944.  
  4945.      -=≡{JOE}≡=- (tm)
  4946. ---------------
  4947. ** Current thread: ETC
  4948.  
  4949. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2GXQ0458 Date: 12/28/89
  4950. From: GRANT ELLSWORTH (Leader)                              Time: 09:07 pm
  4951.   To: JOE VINCENT (Rcvd)                                    (Read 81 times)
  4952. Subj: R: ETC
  4953.  
  4954. Joe, Nice to see you back in "C"-world!  I'm not sure what brought it on,
  4955. but I do know that your investment activity is high and enjoyable.  Hope
  4956. we don't lose you from the arcane world of "haute" computing to the even
  4957. more arcane world of higher finance!  Regards and have a very happy 1990,
  4958. and the decade to come!  Grant
  4959. ---------------
  4960. ** Current thread: ETC
  4961.  
  4962. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2GXQ1270 Date: 12/28/89
  4963. From: PAT SHEA                                              Time: 09:21 pm
  4964.   To: JOE VINCENT (Rcvd)                                    (Read 79 times)
  4965. Subj: R: ETC
  4966.  
  4967. hi joe :
  4968.  
  4969. have been up to my <whatever> in alligators for the last several months at
  4970. work and have not had much time to play around.  'just enjoyed the first
  4971. end-of-year rollover on a new system we put up last autumn - made it with
  4972. only a few minor snags in the f/c'g module (the damned thing was counting
  4973. the last business wk in december as december movement AND also first wk in
  4974. january.)  i've seen some
  4975. really bloody end-of-yr's on new systems.  some take 'til february to iron
  4976. out completely.
  4977. ALSO -
  4978. box up next yr's Christmas stuff and i'll be glad to remail 'm for you.
  4979.  
  4980. best regards,
  4981. pats.
  4982. ---------------
  4983. ** Current thread: ETC
  4984.  
  4985. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2GYM2688 Date: 12/29/89
  4986. From: JOE VINCENT                                           Time: 06:44 pm
  4987.   To: GRANT ELLSWORTH (Rcvd)                                (Read 79 times)
  4988. Subj: R: ETC
  4989.  
  4990. I have plenty of time for my two most enjoyable avocations: PCs and
  4991. investing.  As I have said before, there are none so blind as those who
  4992. will !C (tm) (c).
  4993.  
  4994. Blessed holidays and a prosperous new year to you and yours.
  4995.  
  4996.      -=≡{JOE}≡=- (tm)
  4997. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  4998.  
  4999. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2GXM2455 Date: 12/28/89
  5000. From: WM BAILEY                                             Time: 06:40 pm
  5001.   To: ALL                                                   (Read 76 times)
  5002. Subj: TSR'S
  5003.  
  5004. Does anyone know how to remove ALL tsrs from memory without knowing what
  5005. tsr's were loaded. I have an application where I want to (for security
  5006. purposes) make sure the user does NOT have any tsr's in memory before
  5007. running my program...thus if I find any tsr's there, I could remove them
  5008. with a batch file, or some other method.
  5009.      Alternately, is there a way to 'temporarily' take control of the
  5010. keyboard interupt without effecting my program, but allowing the tsr to
  5011. lose track of it, until I restore it?
  5012.                     Wm Bailey
  5013.                     Modesto, CA
  5014. ---------------
  5015. Following thread
  5016.  
  5017. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2GXQ1206 Date: 12/28/89
  5018. From: GRANT ELLSWORTH (Leader)                              Time: 09:20 pm
  5019.   To: WM BAILEY (Rcvd)                                      (Read 81 times)
  5020. Subj: R: TSR'S
  5021.  
  5022. I think you alrady have half the idea .. To effectively deactivate TSR's
  5023. you need to know 2 sets of things:  a) what the load locations are (whic
  5024. can be derived by running DOS's memeory maps --- See Microsoft's MS-DOS
  5025. Encyclopedia (or other advanced MS-DOS programmers' guides) for details,
  5026. and  b) what the standard interrupt values are when NO TSR's are loaded.
  5027.  
  5028. One crafty approach would be to ADD your own TSR as the 1st loaded (to get
  5029. the base memory location after all TSR's are loaded, and have this new tsr
  5030. capture some out-of-harm's-way interrupt so that re-invokation
  5031. (re-running) of the program could use that interrupt to get back into the
  5032. NEW tsr.  There, in that new TSR interrupt service routine, you could
  5033. re-install the standard interrupts (temporarily or permanently as you
  5034. wish), and delete the other tsr's from memory by returning the memory to
  5035. DOS.  I think there was some sort of utillity to do this in the Mahoney
  5036. collection --- uploaded many many moons ago.  Do a search on "TSR" -- it
  5037. might turn up something.  Grant
  5038. ---------------
  5039. ** Current thread: TSR'S
  5040.  
  5041. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2GY11909 Date: 12/29/89
  5042. From: WM BAILEY                                             Time: 12:31 am
  5043.   To: GRANT ELLSWORTH (Rcvd)                                (Read 91 times)
  5044. Subj: R: TSR'S
  5045.  
  5046. Grant,
  5047.      Thanks for the quick reply. The problem is that this would be on a
  5048. customer's machine, and I wouldn't know what if any TSR's are loaded, and
  5049. also couldn'
  5050. also couldn't load my TSR first, because I wouldn't be there. I'm just
  5051. wondering if when a 'typical PC' is first booted, if the keyboard
  5052. interupts, for instance, are always set the same. If so, why couldn't I
  5053. just reset them to their original 'typical' value and allow the customers'
  5054. TSR to bomb... then load my program. I don't care if his TSR still works
  5055. after running my program or not. I just don't want him to have a TSR that
  5056. can look into memory and find hidden passwords, or other info, while my
  5057. program runs. Except when in memory, everything is encrypted (REALLY
  5058. encrypted!).
  5059.                     Bill
  5060. ---------------
  5061. ** Current thread: TSR'S
  5062.  
  5063. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31M21286 Date: 01/18/90
  5064. From: MARTIN THIRMAN                                        Time: 02:21 am
  5065.   To: WM BAILEY (Rcvd)                                      (Read 91 times)
  5066. Subj: R: TSR'S
  5067.  
  5068. Comment on disabling TSR so that it can't find hidden passwords.
  5069. .
  5070. If they were using a 80386 they could run a spy as a seperate task.
  5071. There are plug in cards that allow one to monitor a system memory.
  5072. Somebody who is determined will find a way to get a look at the memory.
  5073. .
  5074. Have you considerred encrypting the passwords in memory and then use a
  5075. self modifying segment to hide the encrypting and decrypting mechanism.
  5076. Then even if they looked it would be hard to determine the passwords and
  5077. mechanisms.
  5078. (Self modifying segments- Code that modifies itself.)
  5079. You could even tie the encrypting and decrypting into the current date.
  5080. Might make it a little harder.
  5081. I can see all kind of neat ways to encrypt stuff.
  5082. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  5083.  
  5084. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2GXQ0533 Date: 12/28/89
  5085. From: JONCARL MITCHELL                                      Time: 09:08 pm
  5086.   To: ALL                                                   (Read 87 times)
  5087. Subj: C CONVERSION
  5088.  
  5089. How would I convert the following file be  compiled with
  5090. Micro-Soft C 5.1.
  5091. Any Help would be appreciated Thanks JOncarl Mitchell
  5092. ****************
  5093. /*-------------------------------------------------------------------------
  5094. -
  5095.  *     Name     :     memavail.c
  5096.  *     Purpose     :     just prints out available memory to stdout
  5097.  *     Usage     :     memavail >file
  5098.  *     Notes     :     This uses the inline option of TURBO C and is
  5099. compiled
  5100.  *                    in compact model to produce a .COM file
  5101.  
  5102. *--------------------------------------------------------------------------
  5103. */
  5104. #include <stdlib.h>
  5105. #pragma inline
  5106. main()
  5107. {
  5108.      char str[ 18 ];
  5109.      unsigned long i;
  5110.  
  5111.      asm     mov     ah, 48h          /* allocate
  5112. memory                                             */
  5113.      asm mov     bx, 0ffffh     /* alloc
  5114. everything                                        */
  5115.      asm int     21h               /* call DOS, BX is number of paragraphs
  5116. lef               */
  5117.  
  5118.      i = _BX;               /* _BX is the actual BX register, assign to
  5119. LONG i     */
  5120.      i *= 16;               /* * 16 since i == num 16 b
  5121. paragraphs               */
  5122.  
  5123.      ltoa( i, str, 10 );     /* convert long to ascii
  5124. string                              */
  5125.  
  5126.      puts( str );
  5127. }
  5128.  
  5129. /*-------------------------------------------------------------------------
  5130. -*/
  5131. /*
  5132. memavail.c                                        */
  5133. /*-------------------------------------------------------------------------
  5134. -*/
  5135. ---------------
  5136. Following thread
  5137.  
  5138. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2GXQ1449 Date: 12/28/89
  5139. From: GRANT ELLSWORTH (Leader)                              Time: 09:24 pm
  5140.   To: JONCARL MITCHELL (Rcvd)                               (Read 85 times)
  5141. Subj: R: C CONVERSION
  5142.  
  5143. Check back about 3 months in this topic area, I think there was a discus-
  5144. sion on how to get the "TRUE" memory available in MSC 5.x --- where the
  5145. weak standin for TC's "farcoreleft()/coreleft()" did not suffice. Grant
  5146. ---------------
  5147. ** Current thread: C CONVERSION
  5148.  
  5149. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2GY43255 Date: 12/29/89
  5150. From: JONCARL MITCHELL                                      Time: 04:54 am
  5151.   To: GRANT ELLSWORTH (Rcvd)                                (Read 86 times)
  5152. Subj: R: C CONVERSION
  5153.  
  5154. Thanks Grant I'll take a look
  5155. JOncarl
  5156. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  5157.  
  5158. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2GYH0990 Date: 12/29/89
  5159. From: MATTHEW BJURSTROM                                     Time: 01:16 pm
  5160.   To: ROBERT LUNDAHL (Rcvd)                                 (Read 86 times)
  5161. Subj: R: FLASH GRAPHICS
  5162.  
  5163. I've only used the fg library a few times and don't know what troubles you
  5164. are having but I tried writing a simple program (draw some boxes on the
  5165. screen) and it worked fine for me (using v2.0).  I never had a problems
  5166. using v1.07 either but like I said I haven't used either that much.
  5167.      I would say make sure you're including <fg.h> which I'm sure you are,
  5168. and make sure you link the fg library.  This must be done when you compile
  5169. by entering fg.lib on the compiler flags line. ie:
  5170.      Compiler flags: fg.lib
  5171. Beyond this, if you have some specific problem with the fg functions let
  5172. me know and maybe I can try them out.
  5173.      I wonder how many people are using Zortech.  I have used MSC for a
  5174. long time but am switching to learn C++.
  5175. Best regards
  5176. Matt Bjurstrom
  5177. ---------------
  5178. Following thread
  5179.  
  5180. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31111403 Date: 01/01/90
  5181. From: ROBERT LUNDAHL                                        Time: 12:23 am
  5182.   To: MATTHEW BJURSTROM (Rcvd)                              (Read 111 times)
  5183. Subj: R: FLASH GRAPHICS
  5184.  
  5185. I found the problem. It was not Zortech. I had defined a variable
  5186. with the wrong class. Zortech C++ seems to be an excellent
  5187. system. I consider it better than Microsoft.  Thanks...
  5188. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  5189.  
  5190. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 2G^40110 Date: 12/31/89
  5191. From: RENE BOISVERT                                         Time: 04:01 am
  5192.   To: ALL                                                   (Read 82 times)
  5193. Subj: AUTOCAD DWG VECTOR FILE FORMAT
  5194.  
  5195. I'm looking for information on how AutoCad stores its drawing file in
  5196. vector coordinates.  I am writing a program that will read a drawing
  5197. and display it.  I will still need AutoCad to edit and change the
  5198. drawing, but have this other program view it.  I know that there have
  5199. been other programmers doing this, I would appreciate any help.
  5200. What this all entails is a data base that is using the drawings and
  5201. viewing them.
  5202.  
  5203.                   Thanks  -- Rene
  5204.  
  5205.  
  5206. ---------------
  5207.  
  5208. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31BN1774 Date: 01/07/90
  5209. From: DAVID THOMAS                                          Time: 07:29 pm
  5210.   To: GRANT ELLSWORTH (Rcvd)                                (Read 99 times)
  5211. Subj: CASE
  5212.  
  5213. Grant:
  5214.  
  5215. Back in May, 1989 there was a short lived thread on CASE and CASE related
  5216. tools, together with a "lets develop our own" thread.  Did these ideas
  5217. just hit the wall and stick, or is there a current thread I'm not aware
  5218. of?
  5219.  
  5220. I write embedded code on 8 and 16 bit processors for a living, and am very
  5221. interested in any reaction/report on CASE tools, particularly in the
  5222. planning and design phases of projects.  Any comments?
  5223.  
  5224. David
  5225. ---------------
  5226. Following thread
  5227.  
  5228. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31DR2090 Date: 01/09/90
  5229. From: GRANT ELLSWORTH (Leader)                              Time: 10:34 pm
  5230.   To: DAVID THOMAS (Rcvd)                                   (Read 99 times)
  5231. Subj: R: CASE
  5232.  
  5233. David, I'm not aware of any plans for a "CASE" topic/conference here, but
  5234. it might be a good idea.   However, there should be no obstacle and no
  5235. inhibition about discussing CASE in this topic --- particularly if it
  5236. relates to CASE tools which can help C systems developers.
  5237.  
  5238. The most current info I've seen on CASE tools seem to focus on using "Data
  5239. Models" and Information Engineering techniques for generating database
  5240. applications for large organizations.
  5241.  
  5242. While there are other application system implementation aids and program
  5243. generators, they may not fall into the emerging class of CASE
  5244. tools as the MIS community conceives of it.
  5245.  
  5246. With respect to the area you cited, embedded systems, I "evaluated" and
  5247. tried to make sense of a product called "HOS" in 1983.  J. Martin wrote
  5248. about it in "Provably Correct Systems Design" (or Provably Correct
  5249. Programs without Programmers(?)) in that year.  As I recollect, this soft-
  5250. ware idea was something applicable to the general topic of aiding systems
  5251. design and construction without a specific orientation towards database
  5252. applications.   It did generate C code and Fortran code.   I have not
  5253. heard or read anything about the company or the software since 1983.
  5254.  
  5255. Did you have any product or concept in mind?    Grant
  5256. ---------------
  5257. ** Current thread: CASE
  5258.  
  5259. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31HR2412 Date: 01/13/90
  5260. From: JOHN HEIM                                             Time: 10:40 pm
  5261.   To: GRANT ELLSWORTH (Rcvd)                                (Read 93 times)
  5262. Subj: R: CASE
  5263.  
  5264. I used a product by that name about 3 years ago - the company developing
  5265. it went out of business.  I'm not sure it is the same thing but it was a
  5266. code generator.  The package I used was full of bugs - big ones.  My
  5267. apologies to the other HOS if there is another HOS.
  5268.  
  5269. John
  5270. ---------------
  5271. ** Current thread: CASE
  5272.  
  5273. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31IR2596 Date: 01/14/90
  5274. From: GRANT ELLSWORTH (Leader)                              Time: 10:43 pm
  5275.   To: JOHN HEIM (Rcvd)                                      (Read 90 times)
  5276. Subj: R: CASE
  5277.  
  5278. John, The HOS software I looked at/evaluated was put out by an outfit
  5279. called HIGHER-ORDER-SOFTWARE.  Does that name ring a bell?  It wouldn't
  5280. surprise me if this is the same outfit you were referring to; nor would it
  5281. surprise me that this outfit went out of business.  The senior staffers
  5282. and officers I talked to were having some difficulty dealing with reality.
  5283. (to put it politely).  Their idea was interesting, but I never felt it was
  5284. well thought through with respect to real-world applications.  If you
  5285. worked with the product,  can you elaborate a little on your experience
  5286. with it?  I am particularly interested in the type of application you
  5287. were trying to apply it to and how you viewed the product's effectiveness
  5288. for that type of application.  As I vaguely recollect, one of the kernel
  5289. ideas was to enforce highly structured functional decomposition and data
  5290. coupling.  HOS claimed that the software could "prove mathematically" that
  5291. a given design/structure was "correct" and complete prior to code
  5292. generation.  What language did the software you used generate code for?
  5293.  
  5294. Grant
  5295. ---------------
  5296. ** Current thread: CASE
  5297.  
  5298. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31KQ1615 Date: 01/16/90
  5299. From: JOHN HEIM                                             Time: 09:26 pm
  5300.   To: GRANT ELLSWORTH (Rcvd)                                (Read 94 times)
  5301. Subj: R: CASE
  5302.  
  5303. Grant,
  5304.  
  5305. Higher-Order-Software rings a bell - vaguely.  I still can't swear it's
  5306. the same stuff but I think it is.  I agree their idea wasn't well thought
  5307. out for real-world applications.  We had all kinds of trouble making it
  5308. show our real intent.  I was leading a project to develop a grade school
  5309. management package.  The HOS software (we always called it HOSE) created
  5310. a sort of hierarchical data flow diagram.  You created boxes that
  5311. represented processes.  On the left side of the box was a list of the
  5312. program input and on the right was the output.  You started with one box
  5313. that represented a program or system.  Beneath that you could create more
  5314. boxes that represented detailed parts of the program, either modules or
  5315. subroutines.  Each of these boxes had input and output lists.
  5316.  
  5317. The input from the top box was automatically set up as the input of the
  5318. left most box of the 2nd level, the output of the top box was set up as
  5319. the output of the right most box of the 2nd level.  The idea was that you
  5320. would should the data through the various xformations till you got the
  5321. desired output.  I had all kinds of trouble following the rules they had
  5322. set up.  The problem was it wasn't just a DDF diagram tool, they had
  5323. control structures that just wouldn't work within the context of 'all
  5324. inputs must come from somewhere' and 'all processes must have 2 sources of
  5325. input'.  These rules are required for DDF's but dont work in flow charts
  5326. for instance.  PC-useit (the name of HOS's product) was a kind of
  5327. combination of both.
  5328.  
  5329. It did generate code but it wasn't much good.  I seem to remember it being
  5330. in all caps - so it had to be retyped anyway.  Our client insisted we
  5331. supply PC-Useit documents so we put them together as best we could but we
  5332. couldn't use them for coding specs.  We ended up writing the package by
  5333. the seat of our pants (with predictable results).
  5334.  
  5335. In addition to these problems, the software crashed the PC frequently.
  5336.  
  5337. John
  5338. ---------------
  5339. ** Current thread: CASE
  5340.  
  5341. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31KQ3251 Date: 01/16/90
  5342. From: GRANT ELLSWORTH (Leader)                              Time: 09:54 pm
  5343.   To: JOHN HEIM (Rcvd)                                      (Read 92 times)
  5344. Subj: R: CASE
  5345.  
  5346. John, When I "used" HOS, it was a VAX/VMS implementation (circa 1983).
  5347. Other than the PC based operation, your general description sets off the
  5348. alarm bells --- reads like the same thing I looked at.  It is a little
  5349. strange, however, that your output was wired for punch chards (sic) (all
  5350. upper case),,, as I recollect, the one modestly useful thing the HOS could
  5351. produce was mixed case "design" specs.
  5352.  
  5353. On CASE, in general, I keep getting ads, flyers, and other mail on CASE
  5354. stuff --- including a product called POSE (Picture Oriented Software En-
  5355. gineering).  THe ad for POSE purports they have the whole waterfront
  5356. covered from Enterprise Models, thru Data Models, Program Diagrams, etc..
  5357. all the way to code generation.   The vendor is clearly pushing the whole
  5358. Information Engineering Theology and related CASE support tools.  The
  5359. product is PC based, but the code generation spec is sufficiently vague
  5360. that a casual mainframer reader might conclude that it gens code for the
  5361. 370 mainframe cobol db2 applications --- and it very well may.  The prin-
  5362. cipal reason I bring this product to your attention is that it represents
  5363. what I think CASE has come to mean when discussed in MIS (IBM Mainframe
  5364. Shops) circles.  And, as such, I think the ad is a fairly concise state-
  5365. ment of what the elements of CASE are.
  5366.  
  5367. Grant
  5368. ---------------
  5369. ** Current thread: CASE
  5370.  
  5371. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31LQ1513 Date: 01/17/90
  5372. From: JOHN HEIM                                             Time: 09:25 pm
  5373.   To: GRANT ELLSWORTH (Rcvd)                                (Read 93 times)
  5374. Subj: R: CASE
  5375.  
  5376. Grant,
  5377.  
  5378. Last time I investiged CASE tools they were all too expensive and none
  5379. seemed quite what I was looking for.  I read some reviews in several
  5380. different mags and they all indicated that there was some more progress to
  5381. be made before they were really useful.  But I haven't even read a review
  5382. for a couple of years.
  5383.  
  5384. John
  5385. ---------------
  5386. ** Current thread: CASE
  5387.  
  5388. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31LQ2030 Date: 01/17/90
  5389. From: MIKE CODY                                             Time: 09:33 pm
  5390.   To: JOHN HEIM (Rcvd)                                      (Read 87 times)
  5391. Subj: R: CASE
  5392.  
  5393. I personally am not interested in CASE, but PC Mag had a big review thins
  5394. month...you might wish to check it out..
  5395.  
  5396. Mike
  5397. ---------------
  5398. ** Current thread: CASE
  5399.  
  5400. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31LR0808 Date: 01/17/90
  5401. From: GRANT ELLSWORTH (Leader)                              Time: 10:13 pm
  5402.   To: JOHN HEIM (Rcvd)                                      (Read 92 times)
  5403. Subj: R: CASE
  5404.  
  5405. John, I forgot to mention something else on POSE ,,, for PC software, it
  5406. is a bit expensive --- the several components combined runs around $1500
  5407. and the ad compares the product to a $10K class product in terms of func-
  5408. tionality and scope.   The only other full CASE tool set I ever saw or
  5409. got a price on cost around $12K --- way outa sight.
  5410.  
  5411. In general, I have yet to be sold (persuaded) that the data-modelling/
  5412. information-engineering approach to applications planning, design, and
  5413. implementation has the value and benefits it advertises.  However, I HAVE
  5414. seen some earlier components of the planning phase of I/E (e.g. enterprise
  5415. modelling, data modelling) succeed in helping the MIS folks in overcoming
  5416. POLITICAL problems --- ther is where the value may lie.  Grant
  5417. ---------------
  5418. ** Current thread: CASE
  5419.  
  5420. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31MD0918 Date: 01/18/90
  5421. From: JOHN HEIM                                             Time: 09:15 am
  5422.   To: GRANT ELLSWORTH (Rcvd)                                (Read 92 times)
  5423. Subj: R: CASE
  5424.  
  5425. Grant,
  5426.  
  5427. Do you have a preferred design strategy that you use frequently?  Do you
  5428. use the same design strategy for different projects?
  5429.  
  5430. John
  5431. ---------------
  5432. ** Current thread: CASE
  5433.  
  5434. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31NS0379 Date: 01/19/90
  5435. From: GRANT ELLSWORTH (Leader)                              Time: 11:06 pm
  5436.   To: JOHN HEIM (Rcvd)                                      (Read 97 times)
  5437. Subj: R: CASE
  5438.  
  5439. John,  Different types of projects seem to require different design
  5440. stratagies and tactics.  For example, projects for implementing some
  5441. kind of database application where data capture is the prime objective,
  5442. and selective retrieval will be done after data is "stable" begin with
  5443. looking at the data capture problem --- who, how, users, oltp, etc..
  5444. Then procede to looking at who will use the information/data, how, in what
  5445. form(s), etc.. before any database design or application design begins.
  5446. On the other hand, projects implementing system software or communications
  5447. software, original or enhancements, begin by reviewing the functional
  5448. architecture and designing to avoid functional complexity and redundancy.
  5449. Pure OLTP projects generally require bending clean non-redundant data
  5450. storage to the limitations of the data capture environment.  Anyway,
  5451. different types of projects have, or develop, different kinds of
  5452. requirements and priorities --- each will drive the design process on
  5453. different paths.
  5454.  
  5455. For program and module design, I lean very heavily, but not strictly,
  5456. to the functional decomposition strategy described by Glenford Myers
  5457. in his book: Reliable Software through Composite Design.   Unfortunately,
  5458. this approach cannot be applied accross the board --- many projects often
  5459. involve ehancing existing complex program sets which were not well thought
  5460. through with respect to elasticity (allowing for ongoing change) and were
  5461. built when the CPU costs of subroutine calls exceeded the perceived value
  5462. of loosely coupled functional organization of programs.
  5463.  
  5464. What's your inclination with respect to this subject?  Grant
  5465. ---------------
  5466. ** Current thread: CASE
  5467.  
  5468. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31SQ2405 Date: 01/23/90
  5469. From: JOHN HEIM                                             Time: 09:40 pm
  5470.   To: GRANT ELLSWORTH (Rcvd)                                (Read 94 times)
  5471. Subj: R: CASE
  5472.  
  5473. I used to use the same design pattern each time I started a project.  But
  5474. at that time most of the projects I worked on were similar.  You can't use
  5475. the same system to design an accounting apolication and a  software
  5476. engineering project.
  5477.  
  5478. The one interesting thing that I like to use that seems to fit all
  5479. projects is something I've never seen anyone else use except for the
  5480. person who introduced it to me.  He called them Business Functions, I call
  5481. them Definition Functions.  These things are simply a list of things you
  5482. want the program to do.  For instance, suppose your writing a reminder
  5483. program - something to put in autoexec to remind you of your anniversary
  5484. or whatever.
  5485.  
  5486. Some DF's might be - Save a list of dates on disk - Allow option to send
  5487. reminder any number of days before the event - print list of upcoming
  5488. events to screen.  Actually the 'on disk' part of the first DF probably
  5489. doesn't belong there, you're not supposed to be developing implementation
  5490. strategies at this point.  Generally this is the first thing I do when
  5491. starting a project.  If there are end users involved this is the ideal way 
  5492. get them involved in the design.  DF's are supposed to be high level
  5493. enough that even the most non-tech person can contribute.  If the DF's are
  5494. good enough they dont have to be involved much in the techy stuff (which
  5495. really fustrates some people).
  5496.  
  5497. When you're done writing the DF's you group them into modules and that
  5498. leads naturally into hierarchy charts, data flow diagrams and/or
  5499. pseudocode.
  5500.  
  5501. John
  5502. ---------------
  5503. ** Current thread: CASE
  5504.  
  5505. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31TM3087 Date: 01/24/90
  5506. From: GRANT ELLSWORTH (Leader)                              Time: 06:51 pm
  5507.   To: JOHN HEIM (Rcvd)                                      (Read 96 times)
  5508. Subj: R: CASE
  5509.  
  5510. John, That "Business Function" approach is interesting ... and probably
  5511. takes the "politics" out of system design like data modelling.   There's
  5512. an anology to the "Business Function" idea in the Information Engineering
  5513. Methodology --- I don't quite recall what it was.  One of the objectives
  5514. of identifying "business functions" was to derive "subject databases", and
  5515. from those db's, derive the hierarhical structure of the business suport
  5516. applications, etc..  Sound familiar?
  5517.  
  5518. Anyway, I do like some aspects of that approach for developing standard
  5519. MIS database oriented applications.  Most of my projects, however, do not
  5520. fall into that class of projects.  Mine have tended to be special purpose
  5521. data conversion, text searching, mainframe systems support (including dbms
  5522. internalsl) software, or communications software projects.  Different
  5523. requirements, different objectives, etc., each time.   Grant
  5524. ---------------
  5525. ** Current thread: CASE
  5526.  
  5527. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33LG3302 Date: 03/17/90
  5528. From: DAVID THOMAS                                          Time: 12:55 pm
  5529.   To: GRANT ELLSWORTH (Rcvd)                                (Read 89 times)
  5530. Subj: R: CASE
  5531.  
  5532. Grant
  5533.  
  5534. Just ran down the thread regarding CASE and CASE tools which you conducted
  5535. with John Hiem.  I concor with the general tone; code generation may well
  5536. be an illusion.  What I'm interested in are tools aimed at
  5537. design/documentation of software projects, with hooks among graphical,
  5538. textual and source modules.
  5539. There are several principles I find useful in code development; these are
  5540. general attitudes I'd like to see in a CASE tool:
  5541.  
  5542. Iteration is good
  5543.  
  5544. Focused, directed iteration is better
  5545.  
  5546. Structure and flexiblity need not be mutually exclusive
  5547.  
  5548. What does not kill us strengthens us
  5549.  
  5550. Part of the development task is defining the problem, simulations can help
  5551. the user/client/surrogate and the developer better understand the problem
  5552.  
  5553. Avoid oral tradition with respect to product features
  5554.  
  5555. Consise, elegant code is a natural response to a consise, elegant problem
  5556. statement.
  5557.  
  5558. Promote cohesion within modules, reduce coupling among modules.
  5559.  
  5560. This is getting rather far afield.  The bottom line to my desire for
  5561. better design/development tools is that is costs too much to show my
  5562. non-technical marketing/sales user surrogates a hardware/software version
  5563. of an embedded microprocessor controlled product and have them change the
  5564. damned thing.  I want that change as early in the develoment process as I
  5565. can get it, and I want to control/document that change in a relatively
  5566. painless fashion.
  5567.  
  5568. That desire may be wishful thinking, or frustration, or a need to estimate
  5569. costs within an order of magnitude or a simple pursuit of quality software
  5570. or all of the above, but it is important to me.  I normally find that
  5571. implementing a particular piece of a design is straightforward (ie. the
  5572. mechanics of linked list management or unrolling loops in graphic routines
  5573. for the sake of speed, etc.)  What is not straightforward is eliciting the
  5574. requirements/characteristics of the solution from the user, and
  5575. documentingthat solution in a fashion that allows maintainence without
  5576. fear and pain.
  5577.  
  5578. I'd be interested in hearing your comments on the entire mess, for
  5579. instance, is there a definition of "software engineer" that you feel
  5580. comfortable with?  Do we focus too much on technique and not enough on
  5581. design?  Is a segmented address space ala Intel actually a crippling
  5582. feature?    Whatever ......
  5583.  
  5584. David
  5585. ---------------
  5586. ** Current thread: CASE
  5587.  
  5588. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33ME2743 Date: 03/18/90
  5589. From: GRANT ELLSWORTH (Leader)                              Time: 10:45 am
  5590.   To: DAVID THOMAS (Rcvd)                                   (Read 83 times)
  5591. Subj: R: CASE
  5592.  
  5593. David, In the words of one of my ancestors: "You sure slobbered a bib
  5594. full!".  Glad you got something out of the "CASE" thread.  Your own com-
  5595. ments and observations added much to the discussion.  I'm going to d/l
  5596. your essay and make an attempt for a "meaningful" response.  You gave us
  5597. a lot to "cogitate".  Grant
  5598. ---------------
  5599. ** Current thread: CASE
  5600.  
  5601. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33MG3560 Date: 03/18/90
  5602. From: GRANT ELLSWORTH (Leader)                              Time: 12:59 pm
  5603.   To: DAVID THOMAS (Rcvd)                                   (Read 82 times)
  5604. Subj: R: CASE
  5605.  
  5606. David, In more formal response to your essay contribution to the CASE
  5607. discussion ...
  5608.  
  5609. (Part 1 of 2):
  5610.  
  5611. We need to make a distinction between CASE as a DESIGN/DOCUMENTATION
  5612. aid, and CASE as a CODE CREATION (generation) aid.
  5613.  
  5614. You list of "what I'd like to see in a CASE tool" covers both areas.
  5615. Now, in making the distinction, I am not writing that the one purpose
  5616. (design or documentation) substantially supercedes the other. Nor
  5617. would I write that good design and documentation enforces creation of
  5618. more manageable code. Or that manageable well-engineered code is the
  5619. necessarily a product of good well-thought-out design. However, we
  5620. can easily see write/say that good design and good documentation go
  5621. hand in hand.  A design is rubbish if it is not understood.
  5622.  
  5623. Seems to me that we software developers have been too often hamstrung
  5624. by inadequate understanding of the operational and business require-
  5625. ments of the systems we are building. It is here, at the conceptual
  5626. level, that I think CASE tools may be the most helpful. To the extent
  5627. that organizing the requirements and identifying clearly delineated
  5628. functions which correspond to the stated (and presumably understood)
  5629. requirements keeps us from building scrambled eggs / omlette soft-
  5630. ware, CASE tools establish a foundation on which we can make fewer
  5631. mistakes --- and come closer to building something the system buyer
  5632. can use effectively.
  5633.  
  5634. Hence, the ideal CASE tool set would provide a common vocabulary and
  5635. lexicon in which the user, the analyst, the developer(s), and busi-
  5636. ness managers can define the problem accruately. I.e. What trip are
  5637. we taking and is it necessary?   You write that "Part of the develop-
  5638. ment task is defining the problem ....". I'm coming back to the
  5639. notion that : "The BIGGEST part of the development task is defining
  5640. the problem". And here, CASE tools are stronger than using nothing at
  5641. all --- but only for certain classes of applications. Those classes
  5642. most helped are those where end-user access to specific well-organ-
  5643. ized subsets of structured data/information is the objective. In
  5644. other application classes (end-user access to unstructured data,
  5645. "invisible" behavior of programmed micro-processors, communication
  5646. software, operating system software, etc.), CASE tools offer little
  5647. or nothing.
  5648.  
  5649. Anyway, this level of CASE usage does address the voodoo and folklore
  5650. accidental system construction which you correctly identify. The oral
  5651. tradition is fine for myths and legends which gain color and body as
  5652. they are re-told, but, for computer software and hardware systems,
  5653. the lack of precision in the oral tradition is an invitation to a 1st
  5654. class disaster.
  5655.  
  5656. This leads me into the question of CODE CREATION. Effective use of
  5657. CASE for code generation implies that there is a high-level set of
  5658. functions / constructs that the application or system definer/
  5659. builder can activate.  At that level of definition and specification,
  5660. the system builder should not --- or must not --- be aware of or con-
  5661. cerned with such matters as: iteration, loop optimization, etc. After
  5662. all, the objective of CASE is to allow the analysts to build the sys-
  5663. tem in rather precise terms of what it must do ... not how it does
  5664. it at a lower level. This is supposed to reduce the time and per-
  5665. sonnel required to get the job done -- as well as provide some tech-
  5666. niques for quick prototyping and obtaining user feedback.
  5667.  
  5668. Ironically, code creation itself is an issue of specification of
  5669. abstractions. The primary fault of such archaic tools as C***L,
  5670. FORTRAN, etc., is that they do not easily support the degree of
  5671. abstraction in constructs and the re-usability of constructs that
  5672. some of the other tools do. But, in the CASE environment, these prob-
  5673. lems should be as remote from the system builder as Pluto is from the
  5674. sun. So, whether the tool kit generates C***L, C, ALC (370 Assem-
  5675. bler), or other, should be irrelevant and immaterial to the process.
  5676. The code generator can impose its own consistency and "quality" on
  5677. the results.  Here is where the "software engineers" fit in.
  5678.  
  5679. Now, I'm just not sure what "software engineering" is. I think it is an
  5680. academic invention which occurred well after I got my BA. When I took
  5681. a few computer science courses, it was in a converted munitions
  5682. bunker at my local state university. At that time, the focus was on
  5683. the mechanics of building programs, not on the extremely abstract
  5684. mathematical theory allegedly behind the process. All that notwith-
  5685. standing, it seems to me that software engineering, in its formal
  5686. definition and use, is the "search for simplicity by formation of
  5687. extremely contracted abstractions". I'm not yet persuaded it has any
  5688. relevance to the real world or building working systems under the
  5689. constraints of business financial requirements and time constraints.
  5690.  
  5691. As a rule, I think we need to evaluate software according to the
  5692. following criteria:
  5693.  
  5694.   o Usability
  5695.   o Robustness (not breaking unexpectedly at the limits)
  5696.   o Reliability (does not break under extensive normal use)
  5697.   o Testability (can it be tested in discrete units?)
  5698.   o Maintainability (Flexibility, Elasticity, etc)
  5699.  
  5700. ... in that order --- but ALL are very important.
  5701.  
  5702. (continued in next msg)
  5703. ---------------
  5704. ** Current thread: CASE
  5705.  
  5706. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33MH0145 Date: 03/18/90
  5707. From: GRANT ELLSWORTH (Leader)                              Time: 01:02 pm
  5708.   To: DAVID THOMAS (Rcvd)                                   (Read 86 times)
  5709. Subj: R: CASE
  5710.  
  5711. David, ... continuing previous commentary....
  5712.  
  5713. On technique vs design ... Both are important in their own contexts,
  5714. as I think I suggested in my initial comments on the value and use of
  5715. CASE. If anything, I think the wrong folks wind up paying too much
  5716. attention to the wrong issues --- e.g. non-tech managers focusing too
  5717. much on the mechanisms (keep C***L forever --- any learning curve is
  5718. too long), and the software mechanics spend too much time fighting
  5719. over the meaning and the intent of the design in an abstract way ---
  5720. a little time spent as end users (victims of the software system)
  5721. will cure that deficiency. If software builders became better at
  5722. testing and experiencing the mis-behavior of these things they build,
  5723. their ability to interpret designs in terms of usability, as well as
  5724. quality and reliability, will improve substantially.
  5725.  
  5726. On the intel chip's segmented memory architecture, now we get into
  5727. matters of religion and theology. To the mainframer (IBM 370), the
  5728. intel chip is severely brain damaged; to the PC developers, it's
  5729. GOD's way of building CPU's. Having built software in the ASM level
  5730. for IBM 360's/370's, VAX's, 6502, and PC 80x86's, I can only say that
  5731. some provided easier methods to solve some problems and messier
  5732. solutions to others. The 80x86 seems to be surving and growing. Intel
  5733. is not abandoning the fundamental cpu / memory architecture. There
  5734. must be sound engineering reasons for the choice. This may be an
  5735. instance of where there were different ways to solve a problem and
  5736. Intel chose one which worked for them.  IBM bought that approach.
  5737.  
  5738. For my part, I liked the VAX cpu best of the batch. But, I am not
  5739. enough of an electronics expert to understand or comment on the dis-
  5740. advantages and constraints in that architecture. And I don't under-
  5741. stand the problems or constraints of making it available in a true PC
  5742. sized/priced machine.
  5743.  
  5744. Also, although I regard IBM360/370 ALC as my computing mother
  5745. toungue, I recognize the IBM370's most aggrevating constraint. It was
  5746. not a stack machine --- to simulate stack operations in the IBM 370
  5747. architecture is a real pain in the butt -- and I have yet to see it
  5748. done real well. The complexity and cumbersomeness of the whole set of
  5749. operating systems built on that architecture make it increasingly
  5750. cost ineffective to use. The mainframe environment should be "dead
  5751. meat". But will probably survive for a long time --- unless some
  5752. bright outfit comes up with a truly cost-effective method of re-en-
  5753. gineering the billions of lines of obselete C***L applications. CASE
  5754. originally had that promise. However, it is not one I think it is
  5755. currently able to fulfill.
  5756.  
  5757. On the hardware side, the differences between the channel and the bus
  5758. are narrowing considerably. I wouldn't be surprised if this were a
  5759. passe issue by the turn of the century --- if not before.
  5760.  
  5761. I hope these 2 essays addressed the areas you were interested in.
  5762.  
  5763. Add more commentary and questions as you will. Let's see if we can
  5764. get some of our other correspondents in the fray.
  5765.  
  5766. Grant
  5767. ---------------
  5768. ** Current thread: CASE
  5769.  
  5770. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33NR1628 Date: 03/19/90
  5771. From: DAVID THOMAS                                          Time: 10:27 pm
  5772.   To: GRANT ELLSWORTH (Rcvd)                                (Read 86 times)
  5773. Subj: R: CASE
  5774.  
  5775. Grant:
  5776.  
  5777. Thanks for both your time and response.  I agree with your
  5778. "hamstrung" observation; far too often the developers' failure to
  5779. understand the user's context results in the "what do you mean it
  5780. doesn't do that?" confrontation.  This tends to be
  5781. counter-productive at best.
  5782.  
  5783. Have you any exposure to the Yordon development methodology? This
  5784. is a data driven approach, attempting to model a system in terms
  5785. of the data involved, the transformations it undergoes and the
  5786. control events which trigger those changes.  Yordon Inc. (which
  5787. is primarily a consulting firm) sells a CASE package described as
  5788. an editor for Data Flow Diagrams.  A CASE tool survey in PC Tech
  5789. magazine panned the package, objecting to confusing command
  5790. names, poor documentation, EGA only video, etc.  I've never seen
  5791. it run -- the "account specialist" who calls me every couple of
  5792. months keeps pitching a set of seminars (1 day to 5 day) as a
  5793. neccesary prerequisite to the use of the tool.
  5794.  
  5795. I admit to a philosophical attraction to the data driven
  5796. approach.  What is a computer but a method to manipulate data?
  5797. The "Definition Functions" John Heim described have this flavor.
  5798. Focusing on the data feels right; a tool which allows this
  5799. in a flexible, ad hoc fashion while providing usable output (data
  5800. dictionaries, STRUCT definitions/typedefs, where used?) and
  5801. supporting the system documentation  would be a step in the right
  5802. direction.
  5803.  
  5804. I'm unwilling to argue the point, but on second reading my wish
  5805. list seems to revolve entirely about the design/development axis.
  5806. Consise, elegant code is a goal I strive for, not output I expect
  5807. from a code generator (although it would be nice... )
  5808.  
  5809. By the by, there is a POSE slideshow demo in the DOS file
  5810. collection. (POSE.ZIP?)
  5811.  
  5812. Thanks again...
  5813.  
  5814. David
  5815. ---------------
  5816. ** Current thread: CASE
  5817.  
  5818. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33PR1907 Date: 03/20/90
  5819. From: GRANT ELLSWORTH (Leader)                              Time: 10:31 pm
  5820.   To: DAVID THOMAS (Rcvd)                                   (Read 88 times)
  5821. Subj: R: CASE
  5822.  
  5823. David,  Yes, I'm "familiar" with the Yourdon (aka Yourdon-DeMarco) "Meth-
  5824. odology".  I've also some knowledge of the James Martin Information En-
  5825. Gineering approach.  At a slightly lower level, I also have some exposure
  5826. to the Jackson (can't rember the guy's given name right now) data driven
  5827. program construction method(ology).
  5828.  
  5829. Overall, I believe data driven systems design and systems justification
  5830. is appropriate.  It's with respect to program (or application) code
  5831. development that I part ways somewhat with the more formal data driven
  5832. methods ---- they seem a bit incomplete.
  5833.  
  5834. And, I find most offensive and most incredible the claims made by the
  5835. groups above, such as Yourdon, Martin, et al., that they have "the way,
  5836. the truth, and the life" with respect to information systems design
  5837. and implementation.  With each holding that they have a greater grasp
  5838. on their own one true faith than the other.   From my perspective, all
  5839. these data-driven "theologians" are really saying the same things --- some
  5840. very good things, and some very pompous and misleading.  They differ only
  5841. in the words they choose and the puffery they supply.
  5842.  
  5843. Seems to me that your desire/drive for producing elegant strong operation=
  5844. al code is better addressed by such authors as Glenford Myers in his books
  5845. on software design and implementation.  The one I liked the best was:
  5846. Software Reliability through Composite Design.
  5847.  
  5848. It was not only very informative, but very easy to read an understand.
  5849. There was no obfuscation through presentation of highly abstract soft-
  5850. ware metrics theorems and proofs.  It is a pragmatic presentation to
  5851. those wishing to produce usable programs and systems.
  5852.  
  5853. Grant
  5854. ---------------
  5855. ** Current thread: CASE
  5856.  
  5857. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33WM1310 Date: 03/27/90
  5858. From: ERIC MEYER                                            Time: 06:21 pm
  5859.   To: GRANT ELLSWORTH (Rcvd)                                (Read 92 times)
  5860. Subj: R: CASE
  5861.  
  5862. I have never heard that expression before and I thought I would never
  5863. stopped laughing.  I was calling from work and my boss strolled in and
  5864. wondered what the heck I was doing.  (He laughed too.) -Eric
  5865. ---------------
  5866. ** Current thread: CASE
  5867.  
  5868. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33YP1032 Date: 03/29/90
  5869. From: GRANT ELLSWORTH (Leader)                              Time: 08:17 pm
  5870.   To: ERIC MEYER (Rcvd)                                     (Read 83 times)
  5871. Subj: R: CASE
  5872.  
  5873. Glad you folks enjoyed it!  Sometimes it seems we take all these things
  5874. TOO seriously.  Grant
  5875. ---------------
  5876. ** Current thread: CASE
  5877.  
  5878. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34HH1569 Date: 04/13/90
  5879. From: DAVID THOMAS                                          Time: 01:26 pm
  5880.   To: GRANT ELLSWORTH (Rcvd)                                (Read 72 times)
  5881. Subj: CASE
  5882.  
  5883. Grant,
  5884.  
  5885. I obtained a copy of G. Myers' "Reliable Software Through
  5886. Composite Design" and found it interesting on several fronts.
  5887.  
  5888. The first was how relevant the issues he describes (module
  5889. strength, module coupling, structural and functional
  5890. decomposition, etc.) are today, even though the text was
  5891. published in 1975.  The longevity of these concepts is the
  5892. hallmark of fundamental design issues.  You were correct in
  5893. describing this text as a "pragmatic presentation"; I found the
  5894. subsections entitled "Death of a Program" and "Facts of Life"
  5895. quite apropos to my daily work.
  5896.  
  5897. While I may chose to substitute the C term "function" or the
  5898. Pascal term "procedure" for the word "module" in Myers'
  5899. presentation, I found his comments encouraging with respect to
  5900. the design process my intuition desires.
  5901.  
  5902. The second was how tedious the structure charts Myers
  5903. demonstrates are to change and maintain.  As an exersize, I
  5904. re-diagrammed several pieces of a current project, and reached
  5905. the same conclusion I reached about mechanical drawing:  This
  5906. task cries out for automation.
  5907.  
  5908. In that light I've ordered an evaluation copy of a CASE tool
  5909. called "vsDesigner" from Sage Software.  They offer a 30
  5910. evaluation period, at the end of which the product may be
  5911. returned at no charge.
  5912.  
  5913. I'm looking forward to experimenting with this tool, it is
  5914. supposed to allow SQL style query and report generation, multiple
  5915. parent-child module relationships, a smooth graphical interface,
  5916. dada dada dada.  We will see.  I've some hope that it will make
  5917. graphical documentation of some our projects easier.
  5918.  
  5919. Take care...
  5920.  
  5921. David
  5922.  
  5923. ---------------
  5924. ** Current thread: CASE
  5925.  
  5926. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34IS3440 Date: 04/14/90
  5927. From: GRANT ELLSWORTH (Leader)                              Time: 11:57 pm
  5928.   To: DAVID THOMAS (Rcvd)                                   (Read 72 times)
  5929. Subj: R: CASE
  5930.  
  5931. David, Glad to know you finally obtained a copy of that ancient, yet
  5932. reliable, text.  Yes, substituting "function" and "procedure" for Myer's
  5933. "module" concept is quite appropriate.  I took that approach myself.
  5934.  
  5935. Sage Software has a reputation for producing solid mainframe products.
  5936. So, the PC, VSDesigner offering might be a good investment.
  5937.  
  5938. I'm quite curious as to how effective you find the tool.  Please add
  5939. msg to this thread when you have any comments to make about it.  I'm
  5940. sure some of our other correspondents will want to know a little more
  5941. about it too.
  5942.  
  5943. On "automated" assist in system/program structuring, there was a product
  5944. on the market a few years ago called Action Diagrammer, from Knowledgeware
  5945. (now a part of Tarkenton Software).  It was the only product I ever saw
  5946. offered that supposedly would provide assistence in the diagramming of
  5947. program structures --- effectively.  THe HOS product discussed somewhere
  5948. back in this thread attempted to to it, but it never made sense to me
  5949. as a programming aide.
  5950.  
  5951. Also, I saw at an F100 corp shop (several years ago), an interactive
  5952. program diagrammer oriented towards the "Jackson" data driven program
  5953. structure methodology.
  5954.  
  5955. Thus, there have been some serious attempts to provide software tools
  5956. to assist in program / system diagramming.  Maybe this vsDesigner will
  5957. be a useful improvement on the things which have passed that way before.
  5958.  
  5959. Grant
  5960. ---------------
  5961. ** Current thread: CASE
  5962.  
  5963. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34KS2575 Date: 04/16/90
  5964. From: DAVID THOMAS                                          Time: 11:42 pm
  5965.   To: GRANT ELLSWORTH (Rcvd)                                (Read 71 times)
  5966. Subj: CASE
  5967.  
  5968. Grant...
  5969.  
  5970.  btw, there is a shareware CASE product in the Mahoney collection called
  5971. EASYCASE, (EASYCA.ZIP ?) which I've downloaded, but not yet run since
  5972. my wife has the desk rodent.
  5973.  
  5974. David
  5975. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  5976.  
  5977. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31EQ1825 Date: 01/10/90
  5978. From: DALE REID                                             Time: 09:30 pm
  5979.   To: ALL                                                   (Read 99 times)
  5980. Subj: SCREEN POSITION FUNCTION
  5981.  
  5982. I'm real new to C,and have learned it (as well as I have) by scanning
  5983. the manuals, reading some of the tutorials, and adapting another fellows
  5984. code
  5985. (with his blessing) to my needs.  I need to see if there is a function
  5986. which I haven't been able to find in Quick C's manual, the Waite Groups
  5987. Manual on Quick C The Bible, or other stuff I have.  Here is what
  5988. I want to do.. sounds simple...
  5989.  
  5990. My program waits for a certain time to occur, then become active and
  5991. try to sync with a received Satellite passage.  Since other passes may
  5992. occur,
  5993. and other satellites use the same frequecny, I need to delay until
  5994. a certain time.  Fine   _dos_time will do that.  I'd like to be able to
  5995. clear the screen, display a message asking for the start time , get the
  5996. start time (n o problem yet), and THEN, be able to update a display of the
  5997. current time while ticking down.  This means I would like to be able to
  5998. send the cursor to a certain position on the screen and do a printf
  5999. of the time just plucked off by the dos_time function.  But to do this
  6000. each
  6001. second means I have to clear the screen and re-write the whole thing,
  6002. since
  6003. I haven't found the function that allows me to position the cursor to a
  6004. certain row and column before a printf.  Is there one?  There is a
  6005. graphics
  6006. fuction called moveto, but I'm not sure that will work with text,and it
  6007. requires logical screen position rather than an 80 x 24 position.  Any
  6008. help out there for a tenderfoot in C land?  Thanks.  Dale
  6009. ---------------
  6010. Following thread
  6011.  
  6012. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31F41516 Date: 01/11/90
  6013. From: PAT SHEA                                              Time: 04:25 am
  6014.   To: DALE REID (Rcvd)                                      (Read 95 times)
  6015. Subj: R: SCREEN POSITION FUNCTION
  6016.  
  6017. dale :
  6018.  
  6019.    give two these a try. . . .
  6020.  
  6021. /* ------------------SnipSnipSnipSnipSnipSnipSnipSnip---------------- */
  6022. #include <dos.h>
  6023.  
  6024. void vGotoXY( int iCol, int iRow )   /* origin <upper left> is 0,0    */
  6025. {
  6026.    union REGS regs;
  6027.  
  6028.    regs.h.ah = 0x02;             /*  Function 0x02 into AH - INT 0x10 */
  6029.    regs.h.dl = (unsigned char) iCol; /*  Column into DL               */
  6030.    regs.h.dh = (unsigned char) iRow; /*  Row into DH                  */
  6031.    regs.h.bh = 0x00;             /*  Video page 0 in BH               */
  6032.    (void) int86( 0x10, ®s, ®s );
  6033.    return;
  6034. }
  6035.  
  6036. void vCls( void )   /* Get (and Reset to) Current Video Mode = CLS    */
  6037. {
  6038.    union REGS in, out;
  6039.  
  6040.    in.h.ah = 0x0F;
  6041.    (void) int86( 0x10, &in, &out );
  6042.    in.h.ah = 0;
  6043.    in.h.al = out.h.al;
  6044.    (void) int86( 0x10, &in, &out );
  6045.    return;
  6046. }
  6047. /* ------------------SnipSnipSnipSnipSnipSnipSnipSnip---------------- */
  6048.  
  6049. happyhacking!!!
  6050. pats.
  6051. ---------------
  6052. ** Current thread: SCREEN POSITION FUNCTION
  6053.  
  6054. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31FM0545 Date: 01/11/90
  6055. From: DALE REID                                             Time: 06:09 pm
  6056.   To: PAT SHEA (Rcvd)                                       (Read 90 times)
  6057. Subj: R: SCREEN POSITION FUNCTION
  6058.  
  6059. Aha!  I see.  I guess I don't feel that I was TOO stupid, and I'll
  6060. use these dos calls.  Thx again.  I'd still be wearing the pages thin
  6061. looking for a function call to do that.   Dale
  6062. ---------------
  6063. ** Current thread: SCREEN POSITION FUNCTION
  6064.  
  6065. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31HR2959 Date: 01/13/90
  6066. From: JOHN HEIM                                             Time: 10:49 pm
  6067.   To: DALE REID (Rcvd)                                      (Read 88 times)
  6068. Subj: R: SCREEN POSITION FUNCTION
  6069.  
  6070. Dale,
  6071.  
  6072. There's an article in the January (I think) issue of the C User's Journal.
  6073. It's called Spiffier Windows in Turbo C.  It tells how to do something
  6074. very similar to what you're trying to do.  It's in Turbo C but there are
  6075. equivilent functions in QuickC.  If you're new to C (and even if you
  6076. aren't) I'd highly recommend the magazine.
  6077.  
  6078. John
  6079. ---------------
  6080. ** Current thread: SCREEN POSITION FUNCTION
  6081.  
  6082. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31HR3353 Date: 01/13/90
  6083. From: JOHN HEIM                                             Time: 10:55 pm
  6084.   To: DALE REID (Rcvd)                                      (Read 88 times)
  6085. Subj: R: SCREEN POSITION FUNCTION
  6086.  
  6087. Maybe _settextwindow and _settextposition are the fuctions you're looking
  6088. for.
  6089.  
  6090. John
  6091. ---------------
  6092. ** Current thread: SCREEN POSITION FUNCTION
  6093.  
  6094. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31IB1063 Date: 01/14/90
  6095. From: DALE REID                                             Time: 07:17 am
  6096.   To: JOHN HEIM (Rcvd)                                      (Read 87 times)
  6097. Subj: R: SCREEN POSITION FUNCTION
  6098.  
  6099. John ... is this a glossy paper mag that I can find at Egghead or B
  6100. Dalton Software, etc? or a word-of-mouth subscription published on
  6101. xerox paper that I need to know someone who has one to get on the
  6102. mailing list?  Dale
  6103. ---------------
  6104. ** Current thread: SCREEN POSITION FUNCTION
  6105.  
  6106. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31JQ2956 Date: 01/15/90
  6107. From: GRANT ELLSWORTH (Leader)                              Time: 09:49 pm
  6108.   To: DALE REID (Rcvd)                                      (Read 91 times)
  6109. Subj: R: SCREEN POSITION FUNCTION
  6110.  
  6111. Dale,  The C Users Journal is a fairly well-produced journal ... looks
  6112. neatly and cleanly typeset and photo-offset repro.  It does not look like
  6113. a xerox copy made in a back alley.  I have not seen it on any public book
  6114. shelves/bookstores, and I don't think it is an "exclusive word-of-secret-
  6115. word-of-mouth" subscription list.  I got a flyer (ad) for it in the mail
  6116. shorly after I bought TC1.0 and have subscribed to it since.
  6117.  
  6118. Now, it could be I got the flyer because I had just subscribed to DDJ.
  6119. Seems like these computer mag mailing lists really get around.
  6120.  
  6121. Anyway, here's the subscription address if you care to mail a letter of
  6122. inquiry:  C Users Journal, 2120 W. 25th St.  Suite B. Lawrence KS  66047
  6123. Subscription rate is $24/yr and less for 2 and 3 yr renewals.
  6124.  
  6125. I made an understatement, above.  The C User's Journal is in the same
  6126. league with DDJ, CLM, etc.., for quality of typesetting, layout, and
  6127. article content.  It's no "amateur" pub.   And it caters to the same
  6128. advertisers as the other 2 I just mentioned.  Grant
  6129. ---------------
  6130. ** Current thread: SCREEN POSITION FUNCTION
  6131.  
  6132. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31KN0242 Date: 01/16/90
  6133. From: DALE REID                                             Time: 07:04 pm
  6134.   To: GRANT ELLSWORTH (Rcvd)                                (Read 86 times)
  6135. Subj: R: SCREEN POSITION FUNCTION
  6136.  
  6137. Tanks ... Dale
  6138. ---------------
  6139. ** Current thread: SCREEN POSITION FUNCTION
  6140.  
  6141. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31KP3591 Date: 01/16/90
  6142. From: JOHN HEIM                                             Time: 08:59 pm
  6143.   To: DALE REID (Rcvd)                                      (Read 87 times)
  6144. Subj: R: SCREEN POSITION FUNCTION
  6145.  
  6146. RE: C Users' Journal
  6147.  
  6148. Funny you should ask that.  It just went glossy a couple of months ago.
  6149. It's been getting more and more professional looking all the time.  The
  6150. content has always been great though.  I hope some big publisher doesn't
  6151. buy it and turn it into a Byte.  (That's sort of what happened to DDJ and
  6152. Computer Language - if they seem to be less and less techy that's why.)
  6153.  
  6154. CUJ is available at Software Etc and probably lots of other places.
  6155.  
  6156. John
  6157. ---------------
  6158. ** Current thread: SCREEN POSITION FUNCTION
  6159.  
  6160. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31M20974 Date: 01/18/90
  6161. From: MARTIN THIRMAN                                        Time: 02:16 am
  6162.   To: DALE REID (Rcvd)                                      (Read 87 times)
  6163. Subj: R: SCREEN POSITION FUNCTION
  6164.  
  6165. With respect to positioning the cursor to a certain row and column.
  6166. .
  6167. /* with msc5/qc  use _settextposition*/
  6168. /* with turboc use void gotoxy (int x, int y);*/
  6169. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  6170.  
  6171. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31JB3048 Date: 01/15/90
  6172. From: W.K. GORMAN                                           Time: 07:50 am
  6173.   To: ALL                                                   (Read 86 times)
  6174. Subj: XXENCODE/XXDECODE
  6175.  
  6176. I have the C source for these routines, but cannot compile them on my
  6177. machine. Anuone have a compiled version?
  6178. ---------------
  6179. Following thread
  6180.  
  6181. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31JJ0368 Date: 01/15/90
  6182. From: W.K. GORMAN                                           Time: 03:06 pm
  6183.   To: ALL                                                   (Read 86 times)
  6184. Subj: XXENCODE/XXDECODE
  6185.  
  6186. I have source for XXENCODE and XXDECODE (like UUENCODE/UUDECODE) but
  6187. cannot compile it on my machine. Need binary for IBM-PC and/or
  6188. compatibles. Any volunteers to compile?
  6189. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  6190.  
  6191. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31JF2438 Date: 01/15/90
  6192. From: JEFF NOWLAND                                          Time: 11:40 am
  6193.   To: ALL                                                   (Read 88 times)
  6194. Subj: LEAVING MESSAGES
  6195.  
  6196. I've been trying to respond to an old query regarding externally stored
  6197. and accessed routines.  I'm new to these conferencing systems, and the
  6198. replies to the message are all being left as private so I can't tell if
  6199. they are really out there.  How do I get the replies left publicly?
  6200. Thanx, Jeff
  6201. ---------------
  6202. Following thread
  6203.  
  6204. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31JQ3400 Date: 01/15/90
  6205. From: GRANT ELLSWORTH (Leader)                              Time: 09:56 pm
  6206.   To: JEFF NOWLAND (Rcvd)                                   (Read 87 times)
  6207. Subj: R: LEAVING MESSAGES
  6208.  
  6209. What command are you keying to commence your replies?
  6210.  
  6211. Note: an "R" will leave a reply in the same status as the message you are
  6212. replying to.  That is, a reply to a public message will be public, while
  6213. the reply to a private message will be private --- these are the
  6214. "defaults".  If you enter "P", the reply will be private regardless of
  6215. whether the message you are replying to is public.  You can use the "F"
  6216. (fiddle) command to view and alter your message's status before "Sending/
  6217. saving" it.
  6218.  
  6219. Hope this helped a little.  Grant
  6220. ---------------
  6221. ** Current thread: LEAVING MESSAGES
  6222.  
  6223. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31KG1323 Date: 01/16/90
  6224. From: JEFF NOWLAND                                          Time: 12:22 pm
  6225.   To: GRANT ELLSWORTH (Rcvd)                                (Read 83 times)
  6226. Subj: R: LEAVING MESSAGES
  6227.  
  6228. Thanx, I'm sure I was using the "R" command but didn't think to fiddle
  6229. with it.
  6230. J.D.Nowland
  6231. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  6232.  
  6233. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31PI0272 Date: 01/20/90
  6234. From: BILL PREW                                             Time: 02:04 pm
  6235.   To: ALL                                                   (Read 101 times)
  6236. Subj: HUGE ARRAYS IN MSC
  6237.  
  6238.   Okay, all you 'C' jocks out there, I'm looking for a little help
  6239. with the following program.  It's a little utility I whipped up to
  6240. sort the entries in a XTALK file.  The file is in a binary format.
  6241. After skipping the header data, I load the array of entries, and
  6242. then sort it.  The problem I have is the file has gotten bigger than
  6243. 64K, and so I can't use the program as it is.  What I would like to
  6244. do is update the program to handle "Entry" > 64K in size, which I
  6245. think involves "huge" pointers, but I'm not sure what changes are
  6246. needed.  I would like to stick with the Compact Model, and just
  6247. ref the Entry array as huge, is this possible.  Also, will this
  6248. impact on the "qsort" (MSC library routine) or "Compare" functions?
  6249. .
  6250. #include <stddef.h>
  6251. #include <stdlib.h>
  6252. #include <stdio.h>
  6253.  
  6254. #define HeaderSize       467
  6255. #define EntrySize        830
  6256.  
  6257.   struct HeaderStruct
  6258.     {
  6259.     char Filler1[6];
  6260.     int  Entries;
  6261.     char Filler2[459];
  6262.     };
  6263. .
  6264.   struct EntryStruct
  6265.     {
  6266.     char Data[EntrySize];
  6267.     };
  6268.  
  6269. int Compare(char *Key1, char *Key2);
  6270.  
  6271. int main(int argc, char **argv)
  6272.   {
  6273.  
  6274.   FILE *Book;
  6275.   struct EntryStruct *Entry;
  6276.   struct HeaderStruct *Header;
  6277.   int i;
  6278.  
  6279.   if (argc < 2)
  6280.     {
  6281.     printf("Usage:\n");
  6282.     exit(1);
  6283.     }
  6284.  
  6285.   Book = fopen(argv[1], "r+b");
  6286. .
  6287.   Header = (struct HeaderStruct *) malloc(HeaderSize);
  6288.   fread(Header, HeaderSize, 1, Book);
  6289. .
  6290.   Entry = (struct EntryStruct *) halloc((long) Header->Entries,
  6291. EntrySize);
  6292.   fread(Entry, EntrySize, Header->Entries, Book);
  6293. .
  6294.   qsort(Entry, Header->Entries, EntrySize, Compare);
  6295.  
  6296.   fseek(Book, (long) HeaderSize, SEEK_SET);
  6297.   fwrite(Entry, EntrySize, Header->Entries, Book);
  6298.  
  6299.   fclose(Book);
  6300.   exit( 0 );
  6301. }
  6302.  
  6303. int Compare(char *Key1, char *Key2)
  6304. {
  6305.   return( memcmp( Key1, Key2, 8) );
  6306. }
  6307. ---------------
  6308. Following thread
  6309.  
  6310. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31QG3132 Date: 01/21/90
  6311. From: JEFF NOWLAND                                          Time: 12:52 pm
  6312.   To: BILL PREW (Rcvd)                                      (Read 100 times)
  6313. Subj: R: HUGE ARRAYS IN MSC
  6314.  
  6315. Using huge pointers for your array indexing will take care of accessing
  6316. large arrays but you may have to use the huge memory model library
  6317. function for qsort.  ╣
  6318. Also, you may need to place your fread/fwrite calls in a loop because I
  6319. don't think they will let you write more than 64K data in 1 chunk.
  6320. JDN
  6321. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  6322.  
  6323. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31SS1411 Date: 01/23/90
  6324. From: ED ERDMAN                                             Time: 11:23 pm
  6325.   To: ALL                                                   (Read 96 times)
  6326. Subj: 3270 EMULATION
  6327.  
  6328. Has anyone ever seen a "C" library of 3270 emulation functions so that
  6329. one could write custom access programs to control / limit mainframe
  6330. applications when using a PC with an emulation card. The specific case I
  6331. am thinking of is the need for a sort of "preprocessor" for a mainframe
  6332. application that is very weak in it's editing capabilities and for a
  6333. variety of reasons cannot be modified or improved.
  6334. Ed Erdman
  6335. ---------------
  6336. Following thread
  6337.  
  6338. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31TK2882 Date: 01/24/90
  6339. From: TONY SCHLEH                                           Time: 04:48 pm
  6340.   To: ED ERDMAN (Rcvd)                                      (Read 93 times)
  6341. Subj: R: 3270 EMULATION
  6342.  
  6343. Ed,
  6344.   I believed that the NOW! package from Attachmate may do what you are
  6345. looking for.  It always PC/Mainframe scripting that allows you to take
  6346. control of the mainframe side during emulation, check screen, send
  6347. commands.
  6348. Tony Schleh
  6349. ---------------
  6350. ** Current thread: 3270 EMULATION
  6351.  
  6352. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31TQ2523 Date: 01/24/90
  6353. From: ED ERDMAN                                             Time: 09:42 pm
  6354.   To: TONY SCHLEH (Rcvd)                                    (Read 94 times)
  6355. Subj: R: 3270 EMULATION
  6356.  
  6357. Thanks Tony.
  6358. Best Regards,
  6359.             Ed Erdman
  6360. ---------------
  6361. ** Current thread: 3270 EMULATION
  6362.  
  6363. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31US2862 Date: 01/25/90
  6364. From: GLEN THOMPSON                                         Time: 11:47 pm
  6365.   To: ED ERDMAN (Rcvd)                                      (Read 87 times)
  6366. Subj: R: 3270 EMULATION
  6367.  
  6368. Ed,
  6369.  
  6370. I've done some programming that accesses the mainframe through IBM's
  6371. HLLAPI interface.  The routines supplied with 3270 emulation do the job
  6372. pretty well, just akward to use. I've built up a few routines to simplify
  6373. the common tasks like waiting for X-SYSTEM to clear and scanning the
  6374. screen for a string.
  6375.  
  6376. If you're interested in the routines, let me know.
  6377.  
  6378. glen
  6379. ---------------
  6380. ** Current thread: 3270 EMULATION
  6381.  
  6382. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31VL3307 Date: 01/26/90
  6383. From: TONY SCHLEH                                           Time: 05:55 pm
  6384.   To: GLEN THOMPSON (Rcvd)                                  (Read 88 times)
  6385. Subj: R: 3270 EMULATION
  6386.  
  6387. Glen,
  6388.   Attachmate's NOW! package does the same thing (interface to HLLAPI)
  6389. via an easy to use scripting language... Well worth the investment via
  6390. the time savings and mostly structured script coding!
  6391. Tony Schleh
  6392. ---------------
  6393. ** Current thread: 3270 EMULATION
  6394.  
  6395. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31WL1030 Date: 01/27/90
  6396. From: GLEN THOMPSON                                         Time: 05:17 pm
  6397.   To: TONY SCHLEH (Rcvd)                                    (Read 81 times)
  6398. Subj: R: 3270 EMULATION
  6399.  
  6400. Tony,
  6401.  
  6402. The NOW! package is nice but at $195 list per runtime package, it gets a
  6403. little expensive to put it on over 500 PCs.  There are also a number of
  6404. functions that NOW! doesn't support that require a more robust programming
  6405. environment.
  6406.  
  6407. glen
  6408. ---------------
  6409. ** Current thread: 3270 EMULATION
  6410.  
  6411. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31WL2552 Date: 01/27/90
  6412. From: TONY SCHLEH                                           Time: 05:42 pm
  6413.   To: GLEN THOMPSON (Rcvd)                                  (Read 80 times)
  6414. Subj: R: 3270 EMULATION
  6415.  
  6416. Glen,
  6417.   The price would be less than $100.00 per PC with a site licence.
  6418. If there is a robust programming language that is similar to NOW! I
  6419. have not heard of it yet!  I have written systems that use Clipper as
  6420. the base language and shell to NOW for the connectivity.
  6421.  
  6422. I still think that $100 is a small price to pay per PC (even if you
  6423. have 500) considering the increase in productivity by using such a
  6424. program.
  6425.  
  6426. Tony Schleh
  6427. ---------------
  6428. ** Current thread: 3270 EMULATION
  6429.  
  6430. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31ZR1866 Date: 01/30/90
  6431. From: ED ERDMAN                                             Time: 10:31 pm
  6432.   To: GLEN THOMPSON (Rcvd)                                  (Read 80 times)
  6433. Subj: R: 3270 EMULATION
  6434.  
  6435. Hi Glen,
  6436.    I havent tried any of the HLLAPI stuff because the manual indicates
  6437. that I need an IBM brand compiler (C COBOL or BASIC) to use the supplied
  6438. OBJ modules to interface to my code. Am I missing something? I am also
  6439. using a product called EXEC3270 that processes from script like files
  6440. in the DOS window. It works fairly well but I have some users with very
  6441. little memory left over for their DOS windows. (Unfortunately Personal
  6442. Communications 3270 does not use any expanded or extended memory!!) I
  6443. also have users on AEA ports using FTTERM (FTHLLAPI) and would like to be
  6444. able to have something that would appear the same to either type of user.
  6445. Thanks for your response.
  6446. Best Regards,
  6447.             Ed Erdman
  6448. ---------------
  6449. ** Current thread: 3270 EMULATION
  6450.  
  6451. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31^N2555 Date: 01/31/90
  6452. From: T
  6453.  
  6454. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 322R0299 Date: 02/02/90
  6455. From: ED ERDMAN                                             Time: 10:04 pm
  6456.   To: GLEN THOMPSON (Rcvd)                                  (Read 85 times)
  6457. Subj: R: 3270 EMULATION
  6458.  
  6459. Glen,
  6460.      Thanks a lot! I have Turbo C and will try it ASAP.
  6461. Ed
  6462. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  6463.  
  6464. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31UQ1920 Date: 01/25/90
  6465. From: GRANT ELLSWORTH (Leader)                              Time: 09:32 pm
  6466.   To: ALL                                                   (Read 99 times)
  6467. Subj: TC + M$C 5.1 IN OVERLAYS
  6468.  
  6469. Now, here's an interesting problem ... Has anybody written M$C programs as
  6470. OVERLAYS that might be loaded by TC parent programs and then have any of
  6471. several entry points in the overlay (written in M$C) called DIRECTLY from
  6472. the TC parent?
  6473.  
  6474. Does anubody have any thoughts, opinions, or caveats to present on  this
  6475. topic?
  6476.  
  6477. For purposes of this discussion (and the "real_world" constraint), neither
  6478. the TC parent nor the candidate M$C 5.1 overlay program(s) can be
  6479. converted (ported) to the other C varient.
  6480.  
  6481. I think that the M$C 5.1 startup code (CRT0xxx , CHKSTK, and friends)
  6482. could be tinkered with to be the start of an overlay section, but I'm
  6483. wondering what the snakes in this pit are.  Comments?  Examples?
  6484. Guidelines?  No-No's?
  6485.  
  6486. Grant
  6487. ---------------
  6488. Following thread
  6489.  
  6490. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31VN2894 Date: 01/26/90
  6491. From: JEFF NOWLAND                                          Time: 07:48 pm
  6492.   To: GRANT ELLSWORTH (Rcvd)                                (Read 88 times)
  6493. Subj: R: TC + M$C 5.1 IN OVERLAYS
  6494.  
  6495. Grant,
  6496. I uploaded a while back extrout.zip which allows you to write programs
  6497. and link them to .exe files than translate those files to your own
  6498. database format from which you can then load and relocate the program
  6499. yourself.  While this isn't exactly what you intend, I think you can traet
  6500. your problem the same.  The problem you might have is if the M$C program,
  6501. or whichever is to be the child calls the exit(val) function.  This would
  6502. terminate the main program from a DOS call.  If you have the object
  6503. modules and not just an exe file then you could write in your own exit
  6504. function to cause a return to the parent.  Also, if you can do the linking
  6505. yourself then you can write a whole series of functions that would be
  6506. handled by the parent and get two way communication between the parent
  6507. and child processes.  The advantage to doing your own relocation is that
  6508. you won't be stuck with the largest overlay in a block determining the
  6509. block size, you can call the child with any parameters you wish and in
  6510. order you wish as long as the data types between the compilers are
  6511. compatible.  Of course on the down side, anything you do with the external
  6512. routines this way requires that you make sure that the routines are
  6513. present before calling.
  6514. Anyway, you might want to look at the extrout file, it may give you some
  6515. ideas even if it doesn't quite solve this particular problem.
  6516. JDNowland.
  6517. ---------------
  6518. ** Current thread: TC + M$C 5.1 IN OVERLAYS
  6519.  
  6520. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31VN3496 Date: 01/26/90
  6521. From: GRANT ELLSWORTH (Leader)                              Time: 07:58 pm
  6522.   To: JEFF NOWLAND (Rcvd)                                   (Read 85 times)
  6523. Subj: R: TC + M$C 5.1 IN OVERLAYS
  6524.  
  6525. Jeff, That's the kind of "meaty" answer I was hoping for.  Yes, I'll have
  6526. a look at extrout.  Let's see if anybody else has any comments.
  6527.  
  6528. btw, the .OBJ and other non-m$c LIBs with mysterious support functions
  6529. are available --- otherwise , we couldn't discuss building the ASM CRT0xxx
  6530. replacement.
  6531.  
  6532. Thanks,  Grant
  6533. ---------------
  6534. ** Current thread: TC + M$C 5.1 IN OVERLAYS
  6535.  
  6536. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31Y40601 Date: 01/29/90
  6537. From: MARTIN THIRMAN                                        Time: 04:10 am
  6538.   To: GRANT ELLSWORTH (Rcvd)                                (Read 77 times)
  6539. Subj: R: TC + M$C 5.1 IN OVERLAYS
  6540.  
  6541. I have read that one might- use one of the exec functions to load
  6542. and execute a child process in the memory currently occupied by
  6543. your program's code.
  6544. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  6545.  
  6546. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31UR2010 Date: 01/25/90
  6547. From: HENRIK SCHMIEDICHE                                    Time: 10:33 pm
  6548.   To: ALL                                                   (Read 89 times)
  6549. Subj: MSC 6.0
  6550.  
  6551.    Is MSC 6.0 shipping yet? Anybody know anything about it - like whats
  6552. new? Just wondering. Also does anyone know if Borland is going to update
  6553. TurboC 2.0 in the "near" future?
  6554.                                            - Henrik
  6555. ---------------
  6556. Following thread
  6557.  
  6558. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31WM2688 Date: 01/27/90
  6559. From: GRANT ELLSWORTH (Leader)                              Time: 06:44 pm
  6560.   To: HENRIK SCHMIEDICHE (Rcvd)                             (Read 79 times)
  6561. Subj: R: MSC 6.0
  6562.  
  6563. There is a RUMOR in the mill that BI's next TC release which includes a
  6564. C++ support engine is in early beta testing.  Rumor's source is articles
  6565. which imply this in some mag or computing newpaper --- article(s) alleged-
  6566. ly were either written by or used info from the beta testers.  These com-
  6567. ments are my interpretation (and reading between the lines) of some msg
  6568. threads I saw on CIS Borland Support Forum.   Borland is not in the habit
  6569. of announcing new releases well in advance ---- at least in recent years.
  6570. ---------------
  6571. ** Current thread: MSC 6.0
  6572.  
  6573. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31WQ0149 Date: 01/27/90
  6574. From: HENRIK SCHMIEDICHE                                    Time: 09:02 pm
  6575.   To: GRANT ELLSWORTH (Rcvd)                                (Read 77 times)
  6576. Subj: R: MSC 6.0
  6577.  
  6578.    Thanx for the answer. I've been suspecting that TC 2.5)  or TC 3.0
  6579. would go in the direction of C++ - its the next natural step.
  6580.                                               - Henrik
  6581. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  6582.  
  6583. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31VC2676 Date: 01/26/90
  6584. From: VICTOR DURA                                           Time: 08:44 am
  6585.   To: ALL                                                   (Read 93 times)
  6586. Subj: GET ERRORLEVEL FROM C
  6587.  
  6588. Does anyone of a way to check the DOS ERRORLEVEL from within a C
  6589. program? What I would like to do is use the system() procedure
  6590. to execute a DOS command, and then somehow check the ERRORLEVEL
  6591. value. Any suggestions?  Thanks.
  6592. Vic Dura
  6593. ---------------
  6594. Following thread
  6595.  
  6596. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31VN0498 Date: 01/26/90
  6597. From: JOE VINCENT                                           Time: 07:08 pm
  6598.   To: VICTOR DURA (Rcvd)                                    (Read 88 times)
  6599. Subj: R: GET ERRORLEVEL FROM C
  6600.  
  6601. >Does anyone of a way to check the DOS ERRORLEVEL from within a C
  6602. >program? What I would like to do is use the system() procedure
  6603. >to execute a DOS command, and then somehow check the ERRORLEVEL
  6604. >value. Any suggestions?  Thanks.
  6605.  
  6606. Assuming that the DOS command is a .COM, you can get back the ERRORLEVEL
  6607. as the return code if you SPAWN the DOS program; you can't get back the
  6608. return code using system().
  6609.  
  6610.      -=≡{JOE}≡=- (tm)
  6611. ---------------
  6612. ** Current thread: GET ERRORLEVEL FROM C
  6613.  
  6614. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31WB0107 Date: 01/27/90
  6615. From: PAT SHEA                                              Time: 07:01 am
  6616.   To: VICTOR DURA (Rcvd)                                    (Read 83 times)
  6617. Subj: R: GET ERRORLEVEL FROM C
  6618.  
  6619. victor :
  6620.  
  6621. the following code is what i use to check error levels from exe's - you
  6622. should be able to hack it to ur need < msc v5.1 >
  6623.  
  6624. /***********************************************************************
  6625.  *
  6626.  *    ERRLEVEL.C - checks/reports RETURN CODE from executables ....
  6627.  *
  6628.  ******/
  6629.  
  6630. #include <process.h>
  6631. #include <stdio.h>
  6632. #include <string.h>
  6633.  
  6634. void main( int argc, char **argv, char **envp )
  6635. {
  6636.    int iRetCode;
  6637.  
  6638.    if ( argc < 2 ) {
  6639.       fprintf( stderr,
  6640.                "\n\t\tSYNTAX:  %s  <FileName> [arg's] . . .\n\n",
  6641.                strupr( strrchr( argv[0], '\\' ) + 1 ));
  6642.       exit( 255 );
  6643.    }
  6644.    fprintf( stderr,
  6645.             "\n\tCalling %s ....\n\n",
  6646.             strupr( argv[1] ));
  6647.    iRetCode = spawnvpe( P_WAIT, argv[1], argv + 1, envp );
  6648.    fprintf( stderr,
  6649.             "\n\n\t\t%s has returned Error Level =  %d.\n\n",
  6650.             strupr( argv[1] ), iRetCode );
  6651.    exit( 0 );
  6652. }
  6653. ---------------
  6654. ** Current thread: GET ERRORLEVEL FROM C
  6655.  
  6656. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31Y40461 Date: 01/29/90
  6657. From: MARTIN THIRMAN                                        Time: 04:07 am
  6658.   To: VICTOR DURA (Rcvd)                                    (Read 78 times)
  6659. Subj: R: GET ERRORLEVEL FROM C
  6660.  
  6661. I read- On MS-DOS 3.0 or higher, use dosexterr after an error
  6662. return for a DOS function call to obtain detailed info.. on cause
  6663. of error...
  6664. .
  6665. Hopefully, this has some bearing.
  6666. ---------------
  6667. ** Current thread: GET ERRORLEVEL FROM C
  6668.  
  6669. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31YD1772 Date: 01/29/90
  6670. From: VICTOR DURA                                           Time: 09:29 am
  6671.   To: JOE VINCENT (Rcvd)                                    (Read 76 times)
  6672. Subj: R: GET ERRORLEVEL FROM C
  6673.  
  6674. Joe, Thanks for the reply. I need something to handle returned errorlevel
  6675. codes for both com and exe. I'll experiment with spawn though, I've never
  6676. used it befor.
  6677. Vic Dura
  6678. ---------------
  6679. ** Current thread: GET ERRORLEVEL FROM C
  6680.  
  6681. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31YD1901 Date: 01/29/90
  6682. From: VICTOR DURA                                           Time: 09:31 am
  6683.   To: PAT SHEA (Rcvd)                                       (Read 81 times)
  6684. Subj: R: GET ERRORLEVEL FROM C
  6685.  
  6686. Pat, Thanks very much for the detailed suggestion. I'll give it a try!
  6687. BTW, what does the **envp do in the main(...) statement?  Thanks again.
  6688. Vic Dura
  6689. ---------------
  6690. ** Current thread: GET ERRORLEVEL FROM C
  6691.  
  6692. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31YS1010 Date: 01/29/90
  6693. From: GRANT ELLSWORTH (Leader)                              Time: 11:16 pm
  6694.   To: VICTOR DURA (Rcvd)                                    (Read 76 times)
  6695. Subj: R: GET ERRORLEVEL FROM C
  6696.  
  6697. Vic, THe *envp in the main(...) is there to give you a pointer to a
  6698. string of the DOS environment variables (those variables created when you
  6699. issue a "SET VAR=value" command at the DOS prompt or in a .BAT file. Grant
  6700. ---------------
  6701. ** Current thread: GET ERRORLEVEL FROM C
  6702.  
  6703. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31Z33239 Date: 01/30/90
  6704. From: PAT SHEA                                              Time: 03:54 am
  6705.   To: VICTOR DURA (Rcvd)                                    (Read 78 times)
  6706. Subj: R: GET ERRORLEVEL FROM C
  6707.  
  6708. victor :
  6709.  
  6710. the **envp is a pointer to the environment table.   it may <and probably
  6711. is> called something else in your implementation if you are using
  6712. something other than msc.  'suggest that you pull down the manuals and
  6713. check the writeups on the exec??? family of functions - there's a bunch of
  6714. them.  this bunch of function also has some cousins - the spawn family
  6715. that do pretty much do the same thing except with one family, you return
  6716. to the calling program when the 'child' process is done, and do not return
  6717. when using the other.  you use the system() function to excute simple dos
  6718. calls :  the EXEC and SPAWN families call 'third party' programs and are
  6719. diffentiated by whether they return to the caller or not, system() just
  6720. does dos stuff.
  6721. pats.
  6722. ---------------
  6723. ** Current thread: GET ERRORLEVEL FROM C
  6724.  
  6725. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31ZA2981 Date: 01/30/90
  6726. From: VICTOR DURA                                           Time: 06:49 am
  6727.   To: GRANT ELLSWORTH (Rcvd)                                (Read 76 times)
  6728. Subj: R: GET ERRORLEVEL FROM C
  6729.  
  6730. Thanks for the info on *envp, I'll be able to use that in some of my
  6731. code.
  6732. VicDura
  6733. ---------------
  6734. ** Current thread: GET ERRORLEVEL FROM C
  6735.  
  6736. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31ZA3291 Date: 01/30/90
  6737. From: VICTOR DURA                                           Time: 06:54 am
  6738.   To: PAT SHEA (Rcvd)                                       (Read 80 times)
  6739. Subj: R: GET ERRORLEVEL FROM C
  6740.  
  6741. Thanks for the info regarding *envp Pat. I had never seen that befor. As
  6742. I mentioned to Grant, that will come in handy for me. BTW, your suggestion
  6743. about using spawn to get the error level was right on. The code you sent
  6744. me worked perfectly, and was a very instructive example for me as to how
  6745. to use the spawn family of functions correctly. Many thanks for your help.
  6746. VicDura
  6747. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  6748.  
  6749. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31VF2680 Date: 01/26/90
  6750. From: VICTOR DURA                                           Time: 11:44 am
  6751.   To: ALL                                                   (Read 93 times)
  6752. Subj: CALLING FORTRAN FROM C
  6753.  
  6754. Does anyone know anything about calling fortran subroutines from C ?
  6755. I am experimenting with this and am puzzled about somthing. If I define
  6756. a float x=2.2; in C, then pass it to a "void fortran forsub(float *);"
  6757. like so:  forsub(&x);   the value of x in forsub becomes 2200000 (note
  6758. no decimal point). The argument x is defined as real*4 in forsub, but
  6759. attempts to print it with any decimal type format edit descriptors
  6760. such as f7.3, simply yield the number 2200000 as an integer. Arithmetic
  6761. operations on x are performed correctly as if it was an integer value
  6762. of 2200000. E.g. x=2.0*x caused x to become 4400000 within forsub.
  6763. Upon return from forsub, the value of x in the C program would then
  6764. be 4.4! Anybody have any idea what is going on?
  6765. Thanks for your help.
  6766. ...Vic Dura
  6767. ---------------
  6768. Following thread
  6769.  
  6770. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31WI3286 Date: 01/27/90
  6771. From: JOHN HEY                                              Time: 02:54 pm
  6772.   To: VICTOR DURA (Rcvd)                                    (Read 88 times)
  6773. Subj: R: CALLING FORTRAN FROM C
  6774.  
  6775. Would it be possible for you to post a stripped-down version of the code
  6776. that gives you the problem?  One question I have is just how FORTRAN
  6777. distinquishes between arguments passed by value and those passed by
  6778. address (which is what you're doing).  Also, depending on memory models,
  6779. etc, you would have to make sure that the pointer sizes are consistent,
  6780. either both near or both far.  But perhaps you have already checked all of
  6781. that.
  6782. According to my mixed language manual (from MSoft), Fortran arguments
  6783. passed by address are declared with a syntax such as: REAL*4 arg [FAR]
  6784. ---------------
  6785. ** Current thread: CALLING FORTRAN FROM C
  6786.  
  6787. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31WM3339 Date: 01/27/90
  6788. From: GRANT ELLSWORTH (Leader)                              Time: 06:55 pm
  6789.   To: JOHN HEY (Rcvd)                                       (Read 81 times)
  6790. Subj: R: CALLING FORTRAN FROM C
  6791.  
  6792. As nearly as I understand it, MS Fortran, and the other popular fortran
  6793. code receives ALL parameters by address.  Fortran does not pass by value.
  6794.  
  6795. I have a problem I'm working on now that requires me to call routines in a
  6796. FORTRAN based library from TC programs.  I have not yet gotten the whole
  6797. thing to work.  I neglected to note that FORTRAN no only expect (receive)
  6798. all data as FAR pointers, but also use FAR calls in function calls.
  6799. Therefore, safety seems to require use of the LARGE (small pig) memory
  6800. model.   If the FORTRAN code issues NO standard C library calls, then
  6801. other memory models may be used IF all fortran functions and their
  6802. parameters are declared with FAR characteristic.  Grant
  6803. ---------------
  6804. ** Current thread: CALLING FORTRAN FROM C
  6805.  
  6806. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31WM3535 Date: 01/27/90
  6807. From: GRANT ELLSWORTH (Leader)                              Time: 06:58 pm
  6808.   To: VICTOR DURA (Rcvd)                                    (Read 80 times)
  6809. Subj: R: CALLING FORTRAN FROM C
  6810.  
  6811. See my message to John Hey in this thread.  I forgot to "fiddle" to get
  6812. you on the notify list.  Grant
  6813. ---------------
  6814. ** Current thread: CALLING FORTRAN FROM C
  6815.  
  6816. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31XG2034 Date: 01/28/90
  6817. From: JOHN HEY                                              Time: 12:33 pm
  6818.   To: GRANT ELLSWORTH (Rcvd)                                (Read 82 times)
  6819. Subj: R: CALLING FORTRAN FROM C
  6820.  
  6821. This is getting tricky.  On page 15 of my MSC 5.1 manual, in the Mixed
  6822. Languages section, there is a nifty chart which summarizes the way
  6823. arguments are passed, and in FORTRAN the default is by Far address, unless
  6824. the Fortran function is given C calling characteristics, in which case
  6825. arguments are passed by value.  So...
  6826.  
  6827. I guess the best thing would be if the offending code were pared down to
  6828. something quite small, which still manifests this problem, and then we can
  6829. all take a look at it.
  6830.  
  6831. John Hey--
  6832. ---------------
  6833. ** Current thread: CALLING FORTRAN FROM C
  6834.  
  6835. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31XI1231 Date: 01/28/90
  6836. From: JEFF NOWLAND                                          Time: 02:20 pm
  6837.   To: VICTOR DURA (Rcvd)                                    (Read 81 times)
  6838. Subj: R: CALLING FORTRAN FROM C
  6839.  
  6840. VIc,
  6841. I know that different languages have a tendency for using different
  6842. floating point formats.  It sounds like perhaps the bias value in the
  6843. exponent field of floating point numbers in fortran and in C may be
  6844. different. This would cause a magnitude difference when output by C and
  6845. fortran, but since the mathematics and manipulation of the floating point
  6846. values would be the same, just the biasing factor would show up when
  6847. printing the values.  I don't know anything about Microsoft langauges but
  6848. it would seem reasonable to assume that this might be what is happening.
  6849. JDNowland.
  6850. ---------------
  6851. ** Current thread: CALLING FORTRAN FROM C
  6852.  
  6853. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31Y40187 Date: 01/29/90
  6854. From: MARTIN THIRMAN                                        Time: 04:03 am
  6855.   To: VICTOR DURA (Rcvd)                                    (Read 79 times)
  6856. Subj: R: CALLING FORTRAN FROM C
  6857.  
  6858. I have read that - in FORTRAN and Pascal the arguments of the
  6859. function are placed on the stack in the order they appear in the
  6860. function call, exactly the opposite of a C function call.  The
  6861. result is that the first argument in C is always at a fixed
  6862. positive offset ... In FORTRAN, if you do not pass the required
  6863. number of arguments, the addresses computed for each argument
  6864. will be erroneous.
  6865. .
  6866. This may possibly have some bearing on calling Fortran from C.
  6867. ---------------
  6868. ** Current thread: CALLING FORTRAN FROM C
  6869.  
  6870. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31YD1988 Date: 01/29/90
  6871. From: VICTOR DURA                                           Time: 09:33 am
  6872.   To: JOHN HEY (Rcvd)                                       (Read 78 times)
  6873. Subj: R: CALLING FORTRAN FROM C
  6874.  
  6875. John, Thanks for the reply. See my message below to Jeff Nowland.
  6876. Vic Dura
  6877. ---------------
  6878. ** Current thread: CALLING FORTRAN FROM C
  6879.  
  6880. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31YD2078 Date: 01/29/90
  6881. From: VICTOR DURA                                           Time: 09:34 am
  6882.   To: GRANT ELLSWORTH (Rcvd)                                (Read 75 times)
  6883. Subj: R: CALLING FORTRAN FROM C
  6884.  
  6885. Thanks for the reply Grant, see my message to Jeff Nowland for more info
  6886. on
  6887. what I've found out.
  6888. Vic Dura
  6889. ---------------
  6890. ** Current thread: CALLING FORTRAN FROM C
  6891.  
  6892. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31YD2155 Date: 01/29/90
  6893. From: VICTOR DURA                                           Time: 09:35 am
  6894.   To: JEFF NOWLAND (Rcvd)                                   (Read 79 times)
  6895. Subj: R: CALLING FORTRAN FROM C
  6896.  
  6897. > It sounds like perhaps the bias value in the exponent field of
  6898. > floating point numbers in fortran and in C may be different.
  6899.  
  6900. Jeff, I think you may be onto something here. Since I left the message
  6901. last week, about calling fortran from C, I did a little more
  6902. experimenting.
  6903. I found that not only would a float like 2.2 become 220000 when passed
  6904. from C to a fortran subroutine and printed, but even if the floating point
  6905. number is defined in (not passed to) the fortran subroutine, it would
  6906. exhibit the same behavior when printed. E.G., x=4.6 in the fortran
  6907. routine would print as 2200000 when printed with an f7.3 descriptor.
  6908. Near is I can tell, the value of x remains 4.6 for calculations and
  6909. operations; just at output time it come out as 4600000! If I try
  6910. to print x with somthing like I7, I get an error message saying I
  6911. need to use a floating descriptor, so it seems (as you suggest) that
  6912. the fortran routine is indeed internally storing the value as
  6913. a float, or rather real*4. This biasing (scaling?) inconsistency
  6914. only seem to manifest itself when a fortran subroutine, linked to
  6915. a C obj module, prints (outputs?) a floating point number.
  6916. I wonder if there is anyway around this?
  6917. Vic Dura
  6918. ---------------
  6919. ** Current thread: CALLING FORTRAN FROM C
  6920.  
  6921. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31YE1630 Date: 01/29/90
  6922. From: JEFF NOWLAND                                          Time: 10:27 am
  6923.   To: VICTOR DURA (Rcvd)                                    (Read 79 times)
  6924. Subj: R: CALLING FORTRAN FROM C
  6925.  
  6926. You should be able to determine if biasing is the problem by reading the
  6927. advanced programming portion of the manuals.  I know that the Borland
  6928. languages give descriptions of their floating point formats.  Also, I'm
  6929. not sure but I think that there is a wider range of differing types of
  6930. biasing when using the real*4 or float type than when using real*8 or
  6931. double type.  I've seen only one way that the double type has been setup
  6932. in the languages that I have used.  If possible you may wish to try this
  6933. JDNowland.
  6934. ---------------
  6935. ** Current thread: CALLING FORTRAN FROM C
  6936.  
  6937. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31YS0716 Date: 01/29/90
  6938. From: GRANT ELLSWORTH (Leader)                              Time: 11:11 pm
  6939.   To: JOHN HEY (Rcvd)                                       (Read 76 times)
  6940. Subj: R: CALLING FORTRAN FROM C
  6941.  
  6942. John, I got a msg elsewhere that reminded me that the Aug 89 DDJ had an
  6943. article on Fortran/C interfacing.   I think your suspicion bears out from
  6944. what I've seen.  In the much older version of Fortran (Libs) I noted that
  6945. ALL functions are accepting the paramters as Far Pointers --- making all
  6946. functions effectively "call by 'name'".  Grant
  6947. ---------------
  6948. ** Current thread: CALLING FORTRAN FROM C
  6949.  
  6950. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31ZA2744 Date: 01/30/90
  6951. From: VICTOR DURA                                           Time: 06:45 am
  6952.   To: JEFF NOWLAND (Rcvd)                                   (Read 74 times)
  6953. Subj: R: CALLING FORTRAN FROM C
  6954.  
  6955. Thanks for the suggestion Jeff, I'll see what I can find in the manuals
  6956. regarding the floating point formats. I using v4.0 C and fortran, and
  6957. I have a feeling that there may have been a problem with these two
  6958. when linked togeter. I'll see what addition info I and can find, and let
  6959. you know results if anything interesting.
  6960. VicDura
  6961. ---------------
  6962. ** Current thread: CALLING FORTRAN FROM C
  6963.  
  6964. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 32H11000 Date: 02/13/90
  6965. From: VICTOR DURA                                           Time: 12:16 am
  6966.   To: ALL                                                   (Read 76 times)
  6967. Subj: CALLING FORTRAN FROM C
  6968.  
  6969. Does anybody have Microsoft C and Fortran compilers with versions greater
  6970. than 4.0? If so, would you mind compiling the below routines and then
  6971. linking and executing? I'm interested in seeing how the values of
  6972. x and z in forsb2 print out. I have old V4.0 compilers and would like to
  6973. know the results from more recent compilers. Thanks.
  6974. .
  6975. .
  6976. /*  C driver to test call to fortran subroutine. Compile with:
  6977.    cl /c /Od /FPc87 /AL
  6978. then link with forsb.obj
  6979. */
  6980. #include <stdio.h>
  6981. main()
  6982. {
  6983. void fortran forsb2(float *);
  6984. float x;
  6985. x=9.9;
  6986. forsb2(&x);
  6987. }
  6988. C
  6989. C Test fortran subroutine to be called by a C driver. Compile with
  6990. C  fl /c /Od /FPc87 /4Nt
  6991. C then link with test.obj
  6992. C
  6993.       subroutine forsb2(x)
  6994.       z=3.4
  6995.       write(6,20)z
  6996.  20   format('  z=',f7.2)
  6997.       write(6,40)x
  6998.  40   format('  x=',f7.2)
  6999.       return
  7000.       end
  7001. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  7002.  
  7003. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31ZD1124 Date: 01/30/90
  7004. From: GREG HUGHES                                           Time: 09:18 am
  7005.   To: ALL                                                   (Read 77 times)
  7006. Subj: PROGRAMMER NEEDED!
  7007.  
  7008.  
  7009.  
  7010. Are you a hot programmer?
  7011.  
  7012. Our rapidly growing company is becoming a market leader in the OEM
  7013. embedded computer controls industry.  Articles in Control Engineering,
  7014. IEN,
  7015. Electronics Design News, Plant Engineering and several other magazines
  7016. have
  7017. featured our product.
  7018.  
  7019. We have been putting together a team of the most talented people to
  7020. service
  7021. our industry with hardware and software tools.  Currently, we are looking
  7022. for
  7023. a programmer with the following qualifications:
  7024.  
  7025.         1. A BS in Computer Science or Electrical Engineering
  7026.  
  7027.         2. 3+ years experience programming on the IBM PC platform under
  7028. MS-DOS.
  7029.  
  7030.         3. Strong experience with windowing packages or environments such
  7031. as MS-WINDOWS.
  7032.  
  7033.         4. 3+ years experience in C, with knowledge of C++  or another
  7034. object-oriented language a definite plus.
  7035.  
  7036.         5. Assembly language proficiency on the IBM PC.
  7037.  
  7038.         6. Ability to take existing tools and integrate them into a final
  7039. application.
  7040.  
  7041.         7. Strong experience in developing graphical user interfaces.
  7042.  
  7043.  
  7044. The position we are offering will start as a consultant on a project that
  7045. is
  7046. beginning now.  When the project is brought to completion, there is an
  7047. oppurtunity for a salary position.
  7048.  
  7049. Please send me e-mail, or your resume to:
  7050.  
  7051. Personnel Manager/Software Division
  7052. Micro Linear Controls, Inc.
  7053. 2100 Northwestern Ave.
  7054. Racine, WI 53404
  7055. ---------------
  7056.  
  7057. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31^C2353 Date: 01/31/90
  7058. From: VICTOR DURA                                           Time: 08:39 am
  7059.   To: ALL                                                   (Read 74 times)
  7060. Subj: C + FORTRAN COMPILERS?
  7061.  
  7062. Does anybody have Microsoft C and Fortran compilers with versions greater
  7063. than 4.0? If so, would you mind compiling the below routines and then
  7064. linking and executing? I'm interested in seeing how the values of
  7065. x and z in forsb2 print out. I have old V4.0 compilers and would like to
  7066. know the results from more recent compilers. Thanks.
  7067. .
  7068. .
  7069. /*  C driver to test call to fortran subroutine. Compile with:
  7070.    cl /c /Od /FPc87 /AL
  7071. then link with forsb.obj
  7072. */
  7073. #include <stdio.h>
  7074. main()
  7075. {
  7076. void fortran forsb2(float *);
  7077. float x;
  7078. x=9.9;
  7079. forsb2(&x);
  7080. }
  7081. C
  7082. C Test fortran subroutine to be called by a C driver. Compile with
  7083. C  fl /c /Od /FPc87 /4Nt
  7084. C then link with test.obj
  7085. C
  7086.       subroutine forsb2(x)
  7087.       z=3.4
  7088.       write(6,20)z
  7089.  20   format('  z=',f7.2)
  7090.       write(6,40)x
  7091.  40   format('  x=',f7.2)
  7092.       return
  7093.       end
  7094.  
  7095. ---------------
  7096.  
  7097. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31^H2041 Date: 01/31/90
  7098. From: VICTOR DURA                                           Time: 01:34 pm
  7099.   To: PAT SHEA (Rcvd)                                       (Read 79 times)
  7100. Subj: USING SPAWN FUNCTION
  7101.  
  7102. Pat-
  7103. If I may, I would like to ask another question about the SPAWN function.
  7104. At your suggestion I've been studying it, but have not been able to get
  7105. it to work. Below is an example adapted from MSC V4.0 manual. Can you
  7106. give me any insight as to what I'm doing wrong? Thanks
  7107. #include <stdio.h>
  7108. #include <process.h>
  7109. main()
  7110. {
  7111. int status;
  7112. status=spawnlp(P_WAIT, "dir", "*.*", NULL);
  7113. printf(" status = %d\n", status);
  7114. }
  7115. ---------------
  7116. Following thread
  7117.  
  7118. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31^M2406 Date: 01/31/90
  7119. From: JOE VINCENT                                           Time: 06:40 pm
  7120.   To: VICTOR DURA (Rcvd)                                    (Read 79 times)
  7121. Subj: R: USING SPAWN FUNCTION
  7122.  
  7123. Vic, if I might be permitted to comment on your problem with spawn.
  7124.  
  7125. You're trying to execute a "dir" using spawn, but "dir" isn't an
  7126. executable program, it's a resident part ("internal" command) of DOS
  7127. (i.e., of COMMAND.COM).  Second, you'll need to specify the program to be
  7128. executed in the first TWO arguments after the "P_WAIT", like so:
  7129.  
  7130.      spawnlp(P_WAIT,"someprog.exe","someprog.exe","arg1","arg2",NULL);
  7131.  
  7132. For internal DOS commands, "system()" is really the best choice.  If you
  7133. need ERRORLEVEL from DOS programs, "spawn" is the one to use.
  7134.  
  7135.      -=≡{JOE}≡=- (tm)
  7136. ---------------
  7137. ** Current thread: USING SPAWN FUNCTION
  7138.  
  7139. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 321A2009 Date: 02/01/90
  7140. From: VICTOR DURA                                           Time: 06:33 am
  7141.   To: JOE VINCENT (Rcvd)                                    (Read 89 times)
  7142. Subj: R: USING SPAWN FUNCTION
  7143.  
  7144. Joe, thanks for the comments. I just learning C, so I welcome anyone kind
  7145. enough to "jump in" (I call it help) with a suggestion. You may be right
  7146. about the internal command, but I get the same result (return value=-1)
  7147. with any external command. I'll try specifying the command to be executed
  7148. in the first two arguments after P_WAIT. The MSC V4.0 manual doesn't show
  7149. it being specified twice, but I have found several errors in the manual.
  7150. I'll let you know how it turns out.
  7151. Vic Dura
  7152. ---------------
  7153. ** Current thread: USING SPAWN FUNCTION
  7154.  
  7155. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 321F0315 Date: 02/01/90
  7156. From: VICTOR DURA                                           Time: 11:05 am
  7157.   To: JOE VINCENT (Rcvd)                                    (Read 83 times)
  7158. Subj: R: USING SPAWN FUNCTION
  7159.  
  7160. Joe,
  7161. You were right about needing to specify the program to be executed
  7162. two consecutive times after the P_WAIT argument. Also right about
  7163. not being able to spawn the internal command. You won't believe this
  7164. <smile> but the docs make no mention about the external command
  7165. requirement. Thanks for your help on that.
  7166. ---------------
  7167. ** Current thread: USING SPAWN FUNCTION
  7168.  
  7169. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 321F1845 Date: 02/01/90
  7170. From: JEFF NOWLAND                                          Time: 11:30 am
  7171.   To: VICTOR DURA (Rcvd)                                    (Read 83 times)
  7172. Subj: R: USING SPAWN FUNCTION
  7173.  
  7174. Vic,
  7175. The manuals probably don't show the program name being shown twice because
  7176. this is new with DOS version 3.2 and above where the first argument int
  7177. the argv will be the full path name of the the program being executed.
  7178. This can be useful for making sure that you are in the correct dirctory
  7179. when running a program.  Versions of DOS below 3.2 don't do this.
  7180. JDNowland.
  7181. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  7182.  
  7183. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31^N2808 Date: 01/31/90
  7184. From: DIRK MARTIN                                           Time: 07:46 pm
  7185.   To: ALL                                                   (Read 78 times)
  7186. Subj: PROBLEM WITH TLINK
  7187.  
  7188. I've got an application that compiles fine with MS link, and fine with
  7189. Plink86plus.  But when I compile with Tlink, I get "Dgroup : Segment/group
  7190. exceeds 64K".  Anybody got any ideas here?  I kind of remember getting an
  7191. error something like this with MS link in the past, but the exe worked
  7192. fine.  Tlink aborts at the message, and creates no .exe.  Can I get around
  7193. this?  I really like using Tlink because of its speed.  The Turbo C manual
  7194. isn't much help.
  7195. ---------------
  7196. Following thread
  7197.  
  7198. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 321F2211 Date: 02/01/90
  7199. From: JEFF NOWLAND                                          Time: 11:36 am
  7200.   To: DIRK MARTIN (Rcvd)                                    (Read 84 times)
  7201. Subj: R: PROBLEM WITH TLINK
  7202.  
  7203. Dirk,
  7204. The TurboC manual does say that TLink is a "down and dirty" linker and
  7205. that it is not a complete replacement for MS Link.  Depending on what
  7206. compiler you are using to create you object and library modules, there may
  7207. be some record types that are not supported by TLink.  Why this would
  7208. cause that particular message I don't know, but TLink is notorious for not
  7209. handling objects made by other brand compilers.
  7210. JDNowland.
  7211. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  7212.  
  7213. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 31^P1018 Date: 01/31/90
  7214. From: DENNIS DODSON                                         Time: 08:16 pm
  7215.   To: ALL                                                   (Read 81 times)
  7216. Subj: PRINTER CONTROL CODES
  7217.  
  7218. How can I send to the printer the control code to change the printer
  7219. settings to 8 lines per inch, and when done, back to 6 lines per inch ?
  7220. I'm having success with 'condensed' and 'condensed mode off' by using the
  7221. decimal codes (entered with the 'Alt' key and numeric keypad) and the
  7222. 'fprintf' type statement by embedding them as a literal constant.
  7223. The control code for 8 lines/inch is ESC 0 - dec 48 - hex 30, and the
  7224. control code for back to 6 lines/inch is ESC 2 - dec 50 - hex 32.  I've
  7225. tried to embed hex `0x30' type strings, but this hangs the program.
  7226. ....Please Help----Dennis
  7227. ---------------
  7228. Following thread
  7229.  
  7230. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 321D1158 Date: 02/01/90
  7231. From: STEVEN KEY                                            Time: 09:19 am
  7232.   To: DENNIS DODSON (Rcvd)                                  (Read 82 times)
  7233. Subj: R: PRINTER CONTROL CODES
  7234.  
  7235. Dennis,
  7236.  
  7237. I notice that you didn't explicitly say you were sending the ESC character
  7238. - dec 27.  I don't know C, but in Pascal the way you would send a control
  7239. code would look like this : Write( Chr (27)).  I know that C doesn't have
  7240. the strong type checking that Pascal does, but I expect you must still
  7241. tell the compiler you want the single byte 27, not a '2' and '7'.
  7242.  
  7243. In Pascal your 8/in would be Write(Chr(27),Chr(48)).
  7244.  
  7245. Hope this helps.
  7246.  
  7247. Steven
  7248. ---------------
  7249. ** Current thread: PRINTER CONTROL CODES
  7250.  
  7251. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 321F0495 Date: 02/01/90
  7252. From: VICTOR DURA                                           Time: 11:08 am
  7253.   To: DENNIS DODSON (Rcvd)                                  (Read 84 times)
  7254. Subj: R: PRINTER CONTROL CODES
  7255.  
  7256. Dennis,
  7257. Can you give me a few more details about the control codes. I.E., when
  7258. you say: ESC 0 - dec 48 - hex 30
  7259. do you mean the escape character, followed by (the character 0, or a
  7260. zero (null) byte), followed by the characters 4 and 8, or by a byte
  7261. with a value of 48, followed by a byte with value 30?
  7262. In some printers, such as the Panasonic kx-p line, the string:
  7263. ESC+a+2 means the escape character, followed by the "a" character,
  7264. followed by a byte of value=2, not the "2" character. In anycase,
  7265. even if you're using the wrong codes, it shouldn't cause your code
  7266. to hang. Can you show us the exact statements you're using.
  7267. Vic Dura
  7268. ---------------
  7269. ** Current thread: PRINTER CONTROL CODES
  7270.  
  7271. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 321F2595 Date: 02/01/90
  7272. From: JEFF NOWLAND                                          Time: 11:43 am
  7273.   To: DENNIS DODSON (Rcvd)                                  (Read 83 times)
  7274. Subj: R: PRINTER CONTROL CODES
  7275.  
  7276. Dennis,
  7277. You may wish to upload the actual code you've tried here, that may shed
  7278. some light on the problem.  If your control codes are correct then the
  7279. following should work:
  7280. 8 lines/inch:    fprintf(stdprn, "\x1b\x30" );
  7281. 6 lines/inch:    fprintf(stdprn, "\x1b\x32" );
  7282. JDNowland.
  7283. ---------------
  7284. ** Current thread: PRINTER CONTROL CODES
  7285.  
  7286. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 322I3456 Date: 02/02/90
  7287. From: DENNIS DODSON                                         Time: 02:57 pm
  7288.   To: JEFF NOWLAND (Rcvd)                                   (Read 83 times)
  7289. Subj: PRINTER CONTROL CODES
  7290.  
  7291. Thanks Jeff for the helpful information.....
  7292.  
  7293. > 8 lines/inch:  fprintf(stdprn, "\x1b\x30" );
  7294. > 6 lines/inch:  fprintf(stdprn, "\x1b\x32" );
  7295.  
  7296.  .
  7297. I used your examples to write a C program to address the 'stdprn' and set
  7298. it to 6 lines/inch, 8 lines/inch, compressed on, compressed off, or issue
  7299. a form feed based on a command line argument.  This will solve my basic
  7300. printer requirements for the batch jobs that are being developed now for a
  7301. new accounting system we are writing.
  7302.  
  7303. My original problem, though, was not directly involved with a printer
  7304. stream as output, but with outputting a DISK print file (destined for
  7305. later printing from a batch file).  I was not using the ESC "\x1b" as in
  7306. your example, just the hex "\x30" control code in the 'printf'-like
  7307. statements, that was probably why the program was misbehaving as I said.
  7308.  
  7309. Anyway, I did try the 'fprintf' suggestion and tested the ESC and control
  7310. code string to the disk print file, but the results were not as expected.
  7311. It seems NOT to write the 8 lpi control code at all to the front of the
  7312. disk file, and reset back to 6 lpi code at the end of the disk file was
  7313. not
  7314. the expected ascii characters, seemed to write a funny face followed by a
  7315. 2
  7316. I really don't remember exactly, didn't pursue it, and decided that a
  7317. separate C program would suffice anyway.  It would have been nice to embed
  7318. the control codes in the disk file though).
  7319.  
  7320. If you have any other ideas, please holler.  Thanks again for the help.
  7321.  
  7322. Dennis
  7323. ---------------
  7324. ** Current thread: PRINTER CONTROL CODES
  7325.  
  7326. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 325A1714 Date: 02/05/90
  7327. From: VICTOR DURA                                           Time: 06:28 am
  7328.   To: DENNIS DODSON (Rcvd)                                  (Read 84 times)
  7329. Subj: R: PRINTER CONTROL CODES
  7330.  
  7331. Dennis, you're welcome. Glad to help!
  7332. Vic Dura
  7333. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  7334.  
  7335. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 321D1166 Date: 02/01/90
  7336. From: HYONG BANG                                            Time: 09:19 am
  7337.   To: ALL                                                   (Read 81 times)
  7338. Subj: LONGINT SQRT ROUTINES
  7339.  
  7340. Message CC'd to:
  7341.      ALL
  7342.      GRANT ELLSWORTH
  7343.  
  7344. Does anyone have a good inline-able square root routine for longints
  7345. (64 bit)?  Any references or code fragments would be appreciated.
  7346.  
  7347. If it is or could be optimized for a 386 (extended register set), it would
  7348. be lovely.  Thanks
  7349.  
  7350. Hyong Bang
  7351. ---------------
  7352. Following thread
  7353.  
  7354. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 321P0356 Date: 02/01/90
  7355. From: GRANT ELLSWORTH (Leader)                              Time: 08:05 pm
  7356.   To: HYONG BANG (Rcvd)                                     (Read 83 times)
  7357. Subj: R: LONGINT SQRT ROUTINES
  7358.  
  7359. Hyong,  I have not seen anything like a library of in-line math functions.
  7360. You might want to buy a compiler AND its runtime-library sources (if
  7361. available) and "lift" a sqrt() function (most likely already in ASM) and
  7362. modify it for your own purposes.  You won't (or shouldn't) be distribut-
  7363. ing that source (even modified --- it may be restricted), but you could
  7364. include your mod in your own operational code -- which could be
  7365. distributed.   Grant
  7366. ---------------
  7367. ** Current thread: LONGINT SQRT ROUTINES
  7368.  
  7369. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 322E0613 Date: 02/02/90
  7370. From: HYONG BANG                                            Time: 10:10 am
  7371.   To: GRANT ELLSWORTH (Rcvd)                                (Read 85 times)
  7372. Subj: R: LONGINT SQRT ROUTINES
  7373.  
  7374. I've thought of that.  I guess I was hoping to save myself some money.
  7375. I seem to remember that in the earlier days of computing, even for PC's,
  7376. discussions of algoritms were common. But I can seem to find what I
  7377. need in any of my magazines etc.  Thanks for the suggestion anyway.
  7378.  
  7379. Hyong
  7380. ---------------
  7381. ** Current thread: LONGINT SQRT ROUTINES
  7382.  
  7383. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 322F2539 Date: 02/02/90
  7384. From: JEFF NOWLAND                                          Time: 11:42 am
  7385.   To: HYONG BANG (Rcvd)                                     (Read 84 times)
  7386. Subj: R: LONGINT SQRT ROUTINES
  7387.  
  7388. HYONG,
  7389. If its an algorithm you need, try Newton's method:
  7390. To find the square root of a number iterate the following until the
  7391. difference between consecutive approximations is <= 1.
  7392.  next = (number/last+last)/2
  7393. you will need to arbitrarily pick a first approximation and any number
  7394. between 2 and number should work ok.
  7395. :From Assembly Language Programming for the 8086/8088 by Leo Scanlon the
  7396. is a routine for 32-bit integers which should be modifiable to the 386.
  7397. Let me know if you would like to see this.
  7398. JDNowland.
  7399. ---------------
  7400. ** Current thread: LONGINT SQRT ROUTINES
  7401.  
  7402. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 322M3548 Date: 02/02/90
  7403. From: JOE VINCENT                                           Time: 06:59 pm
  7404.   To: HYONG BANG (Rcvd)                                     (Read 88 times)
  7405. Subj: R: LONGINT SQRT ROUTINES
  7406.  
  7407. Hyong, successive approximation is probably the best way to code what you
  7408. want in a straightforward, easily-understood way.  You can calculate a
  7409. square root, for example, by using an initial "guess" for X(0) of 1 and
  7410. generating a "next guess", X(n+1) as .5*(X(n) + (A/X(n)), where "A" is the
  7411. value for which you're trying to calculate the square root.
  7412.  
  7413. For A = 80, X(0) = 1, the "next guess" would be:
  7414.  
  7415.      X(1) = .5 * (1 + 80/1) = 40.5
  7416.      X(2) = .5 * (40.5 + 80/40.5) = 21.23765
  7417.  
  7418. And so on.  This converges very quickly to a value which is accurate to
  7419. several decimal places.
  7420.  
  7421.      -=≡{JOE}≡=- (tm)
  7422. ---------------
  7423. ** Current thread: LONGINT SQRT ROUTINES
  7424.  
  7425. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 325D2460 Date: 02/05/90
  7426. From: STEVEN KEY                                            Time: 09:41 am
  7427.   To: JOE VINCENT (Rcvd)                                    (Read 84 times)
  7428. Subj: R: LONGINT SQRT ROUTINES
  7429.  
  7430. Joe,
  7431.  
  7432. I remember using that algorithm for doing square roots on my first 4
  7433. function calculator in about 1974.  After you get "close", it picks up
  7434. about 2 dicimal places per interation.  I got to be pretty fast at it
  7435. after a few months.
  7436.  
  7437. steven
  7438. ---------------
  7439. ** Current thread: LONGINT SQRT ROUTINES
  7440.  
  7441. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 325G3018 Date: 02/05/90
  7442. From: HYONG BANG                                            Time: 12:50 pm
  7443.   To: JEFF NOWLAND (Rcvd)                                   (Read 88 times)
  7444. Subj: R: LONGINT SQRT ROUTINES
  7445.  
  7446. Thanks for the suggestions.  I'll try and look it up.  The reason I asked
  7447. on the BBS is that as I recall there are much more efficient ways to
  7448. find sqrt's than the Newton's method.
  7449. Hyong
  7450. ---------------
  7451. ** Current thread: LONGINT SQRT ROUTINES
  7452.  
  7453. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 325G3145 Date: 02/05/90
  7454. From: HYONG BANG                                            Time: 12:52 pm
  7455.   To: JOE VINCENT (Rcvd)                                    (Read 82 times)
  7456. Subj: R: LONGINT SQRT ROUTINES
  7457.  
  7458. Thanks for the reply...I was hoping that some one would know of something
  7459. a lot more efficient....
  7460. Hyong
  7461. ---------------
  7462. ** Current thread: LONGINT SQRT ROUTINES
  7463.  
  7464. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 325L3127 Date: 02/05/90
  7465. From: JEFF NOWLAND                                          Time: 05:52 pm
  7466.   To: HYONG BANG (Rcvd)                                     (Read 88 times)
  7467. Subj: R: LONGINT SQRT ROUTINES
  7468.  
  7469. Hyong,
  7470. I don't know if there any more efficient algorithms or not.  I have a
  7471. reference called Computational Mathematics. It was written by a russian
  7472. mathematician and has quite a few algoritms. I could check it for
  7473. information.  Also, if you code Newton's method in assembler optimized for
  7474. 386 then you would probably get the efficiency you want.  Also, if you
  7475. have a math coprocessor available I believe there are 80x87 op codes for
  7476. dealing with the 64bit long integer format.  These would be more efficient
  7477. than any algorithm you are likely to find(???). It might help if we all
  7478. knew what compiler you are using, I don't recall a C compiler with the
  7479. 64bit integer type.
  7480. But then again, I don't look too much.
  7481. JDNowland.
  7482. ---------------
  7483. ** Current thread: LONGINT SQRT ROUTINES
  7484.  
  7485. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 32AM0726 Date: 02/06/90
  7486. From: HYONG BANG                                            Time: 06:12 pm
  7487.   To: JEFF NOWLAND (Rcvd)                                   (Read 87 times)
  7488. Subj: R: LONGINT SQRT ROUTINES
  7489.  
  7490. Actually, I'm using TP rather than TC (long story).  I do have a 387, but
  7491. the code may (probably) should run on systems without, is why I've
  7492. been asking around.
  7493.  
  7494. I thought the people on this conference might have had something
  7495. at their finger tips, but I guess no one needs to code math routines
  7496. by hand much anymore.
  7497.  
  7498. Thanks for your remarks.
  7499. Hyong
  7500. ---------------
  7501. ** Current thread: LONGINT SQRT ROUTINES
  7502.  
  7503. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 32AN1630 Date: 02/06/90
  7504. From: PAT SHEA                                              Time: 07:27 pm
  7505.   To: HYONG BANG (Rcvd)                                     (Read 89 times)
  7506. Subj: R: LONGINT SQRT ROUTINES
  7507.  
  7508. hyong :
  7509.  
  7510. 'dug thru my drek heap and came up w/ the following.  i have used it to
  7511. avoid loading the fp emulator on several applications.  you may be able to
  7512. use it as a skeleton even though it only works <as written> on 16-bit
  7513. arg's - logic is the same for 'longs', you just have to make a few
  7514. adjustments in the code.  BTW:  i have not really looked at this code in
  7515. quite some time - the only thing i can testify to is that it is filed in
  7516. with stuff that works <as opposed to stuff that doesn't - which is in a
  7517. nother directo>
  7518.  
  7519. #define TEST   /*   This TEST checks the accuracy of the integer square
  7520.                 *   root generated by the function vs. that generated by
  7521.                 *   MATH.LIB's sqrt(), rounded, and truncated.
  7522.                 *
  7523.                 *   NOTE:  The test will take > 5 min. on a 4.77 Mhz
  7524.                 *          (stock, std. issue) IBM XT.
  7525.                 *****/
  7526.  
  7527. /***********************************************************************
  7528.  *
  7529.  *    SYNTAX -
  7530.  *       extern int int_sqrt( unsigned int numb );
  7531.  *
  7532.  *    RETURNS -
  7533.  *       Integer square root of the unsigned integer argument.
  7534.  *       The return is the integer value closest to the 'real'
  7535.  *       square root.  You can simulate higher precision by
  7536.  *       multiplying the argument by 100, 10000, etc. within
  7537.  *       the function and making requisite corrections in the
  7538.  *       calling function.
  7539.  *
  7540.  *       HOWEVER, the bigger the number is that the function is
  7541.  *       processing, the slower it will run.  With an argument
  7542.  *       of about 25000 or less, speed is comparable (or even
  7543.  *       faster than) math.lib's sqrt() on a machine without an
  7544.  *       NDP.  As the argument approaches 64K, speed dwindles to
  7545.  *       25-30% of math.lib.
  7546.  *
  7547.  *
  7548.  *****/
  7549.  
  7550. #define SQUARE( x ) (( x ) * ( x ))
  7551.  
  7552. extern int int_sqrt( unsigned int numb );
  7553.  
  7554. int int_sqrt( unsigned int numb )
  7555. {
  7556.    long old_numb, long_numb, test_root, odd_numb = 1L;
  7557.  
  7558.    old_numb = long_numb = (long) numb;
  7559.    while ( long_numb >= 0L ) {
  7560.       long_numb -= odd_numb;
  7561.       odd_numb += 2L;
  7562.    }
  7563.    test_root = (unsigned long) odd_numb >> 1;
  7564.    return( (int)(( SQUARE( test_root ) - test_root + 1L > old_numb ) ?
  7565.            ( test_root - 1L ) : test_root ));
  7566. }
  7567.  
  7568. #ifdef TEST
  7569.  
  7570. #include <stdio.h>
  7571. #include <stdlib.h>
  7572. #include <math.h>
  7573.  
  7574. extern void main( void );
  7575.  
  7576. void main( void )
  7577. {
  7578.    unsigned int j;
  7579.    int root;
  7580.    double root_87, adj_root_87, error_root;
  7581.  
  7582.    for ( j = 0; j < 65000; j++ ) {
  7583.       root = int_sqrt( j );
  7584.       root_87 = sqrt( (double) j );
  7585.       adj_root_87 = floor( root_87 + 0.5 );
  7586.       error_root = (double) root - adj_root_87;
  7587.       if ( error_root != 0.0 || j % 1000 == 0 ) {
  7588.          printf( "\t%5u\tint_sqrt - %3d\tsqrt - %5.8f\tERROR - %3.6G\n",
  7589.                   j, root, root_87, (double) root - adj_root_87 );
  7590.       }
  7591.    }
  7592.    exit( 0 );
  7593. }
  7594.  
  7595. #endif   /*  TEST  */
  7596.  
  7597. happyhacking!!!
  7598. pats.
  7599. ---------------
  7600. ** Current thread: LONGINT SQRT ROUTINES
  7601.  
  7602. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 32BC1126 Date: 02/07/90
  7603. From: STEVEN KEY                                            Time: 08:18 am
  7604.   To: HYONG BANG (Rcvd)                                     (Read 82 times)
  7605. Subj: R: LONGINT SQRT ROUTINES
  7606.  
  7607. Hyong,
  7608.  
  7609. In going through an last years Dr Dobbs to file articles, I found a letter
  7610. to the editor that recommends SOFTWARE MANUAL for ELEMENTARY FUNCTIONS by
  7611. William Cody and William Waite, Prentice-Hall.  "Gives detailed
  7612. inplementations of sqrt,alog, alog10, exp, power, sin, cos, tan, cot,
  7613. asin, acos, atan, atan2, sinh, cosh, tanh, and provides a test suite."
  7614.  
  7615. Steven
  7616. ---------------
  7617. ** Current thread: LONGINT SQRT ROUTINES
  7618.  
  7619.  
  7620. Chain->z5╙
  7621. >>> Inactivity warning:  One minute to automatic logoff!
  7622. 
  7623. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 32BR1223 Date: 02/07/90
  7624. From: ERIC JABLOW                                           Time: 10:20 pm
  7625.   To: HYONG BANG (Rcvd)                                     (Read 90 times)
  7626. Subj: R: LONGINT SQRT ROUTINES
  7627.  
  7628. I've mentioned this reference in the past, but here goes:
  7629. Look for Numerical Recipes in Pascal, from Cambridge University Press.
  7630. (They also publish a FORTRAN and a C version.)  It's a very good
  7631. reference.  If you can stand the theory, look at the book Pi and the AGM,
  7632. by Jonathan and Peter Borwein; this describes the methods used to
  7633. calculate the first N digits of pi and other unusual problems.
  7634. These methods use the square root, but it will show you various methods to
  7635. calculate other math functions.  But watch out; it's really high-powered
  7636. stuff.
  7637.  
  7638. Have you seen Concrete Mathematics, by Graham, Knuth, and Patashnik yet?
  7639.  
  7640. Eric Jablow
  7641. ---------------
  7642. ** Current thread: LONGINT SQRT ROUTINES
  7643.  
  7644. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 32CD1372 Date: 02/08/90
  7645. From: HYONG BANG                                            Time: 09:22 am
  7646.   To: PAT SHEA (Rcvd)                                       (Read 86 times)
  7647. Subj: R: LONGINT SQRT ROUTINES
  7648.  
  7649. Thanks...I'll look at it and see how it works.
  7650.  
  7651. Hyong
  7652. ---------------
  7653. ** Current thread: LONGINT SQRT ROUTINES
  7654.  
  7655. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 32CD1463 Date: 02/08/90
  7656. From: HYONG BANG                                            Time: 09:24 am
  7657.   To: STEVEN KEY (Rcvd)                                     (Read 91 times)
  7658. Subj: R: LONGINT SQRT ROUTINES
  7659.  
  7660. Thanks for the reference.  It's one I haven't run across in the local
  7661. book stores.
  7662.  
  7663. Hyong
  7664. ---------------
  7665. ** Current thread: LONGINT SQRT ROUTINES
  7666.  
  7667. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 32CD1639 Date: 02/08/90
  7668. From: HYONG BANG                                            Time: 09:27 am
  7669.   To: ERIC JABLOW (Rcvd)                                    (Read 91 times)
  7670. Subj: R: LONGINT SQRT ROUTINES
  7671.  
  7672. Yes, to Recipes, No to Pi and AGM (heard of it, but never seen it- local
  7673. library and book stores are REALLY sparse), Not even heard of Concrete-
  7674. Care to tell me more about it? I have a tendency to collect books by
  7675. Knuth (the same Knuth?).
  7676.  
  7677. Hyong
  7678. ---------------
  7679. ** Current thread: LONGINT SQRT ROUTINES
  7680.  
  7681. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 32CR3537 Date: 02/08/90
  7682. From: ERIC JABLOW                                           Time: 10:58 pm
  7683.   To: HYONG BANG (Rcvd)                                     (Read 99 times)
  7684. Subj: R: LONGINT SQRT ROUTINES
  7685.  
  7686. Yes, the same Knuth.  Ronald Graham, Donald Knuth, and Oren [?] Patashnik.
  7687. basically, it's an enlarged version of Ch. 1 of Knuth's Art of Computer
  7688. Programming.
  7689.  
  7690. The book is probably by Addison Wesley--check out Books in Print, and
  7691. check out libraries near you, I guess.  The book on Pi is not as essential
  7692. to you, I guess.  It's published by Wiley, I think.
  7693.  
  7694. Eric
  7695. ---------------
  7696. ** Current thread: LONGINT SQRT ROUTINES
  7697.  
  7698. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 32DI1560 Date: 02/09/90
  7699. From: JEFF NOWLAND                                          Time: 02:26 pm
  7700.   To: HYONG BANG (Rcvd)                                     (Read 120 times)
  7701. Subj: R: LONGINT SQRT ROUTINES
  7702.  
  7703. ;Hyong,
  7704. ;
  7705. ; Know you're not impressed with Newton's method, but we do know
  7706. ; assembler and this is for 386 register set so the inefficiency
  7707. ; of the algorithm(???) should be offset by the efficiency of
  7708. ; assembly and doing this inline. If you can get your longint
  7709. ; into edx:eax, this will
  7710. ; replace it with square root in edx:eax for you to get it back.
  7711. ; I don't know anything about TP's inline other than you (used to?)
  7712. ; need to use opcodes, so you'll have to assemble this and use the
  7713. ; assembler list to get your opcodes. I don't have a compiler with
  7714. ; 64 bit longints to test this and I don't have time to create my
  7715. ; own 64 bit longint type, so make sure you test. I did however verify
  7716. ; its accuracy when the source number can be represented by a 32 bit
  7717. ; integer.
  7718. ;
  7719.  
  7720. .386
  7721. _TEXT       segment byte public 'CODE' USE16
  7722.             assume  cs:_TEXT
  7723. _sqrt64_386 proc
  7724.             or      edx,edx      ; first make sure source is > 1
  7725.             jne     FindRoot     ; otherwise sqrt(source)=source
  7726.             cmp     eax,2
  7727.             jae     FindRoot
  7728.             jmp     ReallyDone
  7729. FindRoot:   push    bp           ; save base pointer
  7730.             push    edx
  7731.             push    eax
  7732.             mov     bp,sp
  7733.             xor     edx,edx      ; make the first guess 2
  7734.             mov     eax,2
  7735. GetNext:    mov     ebx,eax      ; get current guess
  7736.             mov     ecx,edx
  7737.             mov     edx,[bp+4]   ; restore our source number
  7738.             mov     eax,[bp]
  7739.             or      edx,edx      ; if edx is 0 then we can use the
  7740.             je      DivEasy      ; processor's div instruction
  7741.                                  ; otherwise we have to do division
  7742.                                  ; by shifting registers.
  7743.             push    bp           ; need to save some registers
  7744.             push    si           ; Only saving lower 16 bits
  7745.             push    di           ; compiler doesn't access upper bits
  7746.             mov     ebp,ecx      ; high dword of denominator to EBP so
  7747.             mov     ecx,64       ; ECX can be used as a loop counter.
  7748.                                  ; shift through 64 bits
  7749.             xor     edi,edi      ; temporary shift overflow register
  7750.             xor     esi,esi
  7751. DivLoop:    shl     eax,1        ; shift numerator left 1 bit
  7752.             rcl     edx,1
  7753.             rcl     esi,1        ; and move carry into temporary
  7754.             rcl     edi,1
  7755.             cmp     edi,ebp      ; check to see if we've shifted back
  7756.             jb      EndLoop      ; into our answer
  7757.             ja      SubDenom
  7758.             cmp     esi,ebx
  7759.             jb      EndLoop
  7760. SubDenom:   sub     esi,ebx      ; subtract denominator
  7761.             sbb     edi,ebp      ; move a new bit into answer
  7762.             inc     eax
  7763. EndLoop:    loop    DivLoop      ; when finished EDX:EAX will
  7764.                                  ; quotient
  7765.             mov     ecx,ebp      ; high dword of guess back to ECX
  7766.             pop     di           ; restore saved registers
  7767.             pop     si
  7768.             pop     bp
  7769.             jmp     short DivDone; division complete
  7770. DivEasy:    div     ebx          ; no overflow use processor's div inst
  7771.             xor     edx,edx      ; and lose the remainder
  7772. DivDone:    add     eax,ebx      ; add current guess to quotient
  7773.             adc     edx,ecx
  7774.             shr     edx,1        ; and divide by 2
  7775.             rcr     eax,1
  7776.             cmp     edx,ecx      ; significant change
  7777.             jne     GetNext      ; between successive guesses?
  7778.             sub     ebx,eax
  7779.             jz      Done
  7780.             cmp     ebx,1
  7781.             je      Done
  7782.             cmp     ebx,-1
  7783.             jne     GetNext
  7784. Done:       add     sp,8         ; make stack right
  7785.             pop     bp           ; answer is in EDX:EAX
  7786. ReallyDone:
  7787. _sqrt64_386 endp
  7788. _TEXT       ends
  7789.             end
  7790.  
  7791. ;Happy Hunting!!
  7792. ;
  7793. ;JDNowland.
  7794. ;
  7795. ; P.S. Credits go to Leo Scanlon(Assembly Language Programming for
  7796. ;      8086/88) for 8086 version of 32 bit integer newton's method, and
  7797. ;      Borland International for 8086 division routine taking overflow
  7798. ;      into account for 32 bit integers.
  7799. ;
  7800. ---------------
  7801. ** Current thread: LONGINT SQRT ROUTINES
  7802.  
  7803. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33GE2516 Date: 03/12/90
  7804. From: HYONG BANG                                            Time: 10:41 am
  7805.   To: JEFF NOWLAND (Rcvd)                                   (Read 77 times)
  7806. Subj: R: LONGINT SQRT ROUTINES
  7807.  
  7808. Thanks for the code; will be sure to test it...as you can see by the date
  7809. of this reply, it's been a while since I last logged on to this BBS.
  7810. Hyong Bang
  7811. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  7812.  
  7813. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 322B1062 Date: 02/02/90
  7814. From: DINO BIONDO                                           Time: 07:17 am
  7815.   To: ALL                                                   (Read 86 times)
  7816. Subj: ASSIGN A STRING TO A STRUCTURE
  7817.  
  7818. Help I need to know how to assign a string to a structure. here is what im
  7819. trying to do.  i have a structure built with multiple members, each member
  7820. is of the char type ex  struct  test { char fld01[30]; char fld02[30]; };
  7821. next i am reading a file sequentially via the gets() function and filling
  7822. a buffer area with 60 bytes. what i want to do is take that buffer and
  7823. assign it to my structure. so i can access the members.  Some thing
  7824. similar to a cobol read into command.  any help and suggestions would make
  7825. my life and boss very happy..... Thanks Dino
  7826. ---------------
  7827. Following thread
  7828.  
  7829. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 322F3063 Date: 02/02/90
  7830. From: JEFF NOWLAND                                          Time: 11:51 am
  7831.   To: DINO BIONDO (Rcvd)                                    (Read 80 times)
  7832. Subj: R: ASSIGN A STRING TO A STRUCTURE
  7833.  
  7834. Dino,
  7835. Try the following when reading the file:
  7836. func{
  7837. struct test t;
  7838. FILE *f;
  7839.        while( fgets(t.fld01,30,f) != NULL ) { fgets(t.fld02,30,f); }
  7840. }
  7841. This way you directly fill your structure rather than using the
  7842. intermediate step of building a 60 byte buffer then copying data to your
  7843. structure. Note that this will read a maximum of 29 characters for each
  7844. field rather than 30, thus leaving room for your terminating '\0'.
  7845. JDNowland
  7846. ---------------
  7847. ** Current thread: ASSIGN A STRING TO A STRUCTURE
  7848.  
  7849. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 322M2931 Date: 02/02/90
  7850. From: JOE VINCENT                                           Time: 06:48 pm
  7851.   To: DINO BIONDO (Rcvd)                                    (Read 84 times)
  7852. Subj: R: ASSIGN A STRING TO A STRUCTURE
  7853.  
  7854. Dino, if you assign the buffer and the structure to the same memory space
  7855. using "union", you should get what you want.
  7856.  
  7857.      -=≡{JOE}≡=- (tm)
  7858. ---------------
  7859. ** Current thread: ASSIGN A STRING TO A STRUCTURE
  7860.  
  7861. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 325B0626 Date: 02/05/90
  7862. From: DINO BIONDO                                           Time: 07:10 am
  7863.   To: JOE VINCENT (Rcvd)                                    (Read 82 times)
  7864. Subj: R: ASSIGN A STRING TO A STRUCTURE
  7865.  
  7866. Thanks Joe, I will give that a try..... Dino
  7867. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  7868.  
  7869. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 322H0548 Date: 02/02/90
  7870. From: DINO BIONDO                                           Time: 01:09 pm
  7871.   To: JEFF NOWLAND (Rcvd)                                   (Read 79 times)
  7872. Subj: REPLY TO MESSAGE SENT TO DINO
  7873.  
  7874. Thanks Jeff,, It seems so simple now...... I appreciate the help and hope
  7875. i can return the favor sometime.     Dino
  7876. ---------------
  7877.  
  7878. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 322M3219 Date: 02/02/90
  7879. From: GRANT ELLSWORTH (Leader)                              Time: 06:53 pm
  7880.   To: ALL                                                   (Read 87 times)
  7881. Subj: TURBO C 2.0X MAKE
  7882.  
  7883. Has ANYBODY suceeded in getting Borland's MAKE utility to work with
  7884. multiple conditions?  Very simple conditions!
  7885.  
  7886. I am unable to get MAKE to process more than the 1st condition in the
  7887. following simple-minded example:
  7888.  
  7889. myfile1.obj:
  7890.   tlib /C mylib -+$*, mylib.lis
  7891.  
  7892. myfile2.obj:
  7893.   tlib /c mylib -+$*, mylib.lis
  7894.  
  7895. myfile3.obj:
  7896.   tlib /C mylib -+$*, mylib.lis
  7897.  
  7898. Command line was: make -fmymake.mak
  7899.  
  7900. I also tried the following:
  7901.  
  7902. o created file named: makfile.mak (MAKE's default filename for input)
  7903.  
  7904. o explicitly replaced the $* in the command lines with the name of the
  7905.   object file
  7906.  
  7907. ... still no further processing after 1st condition (myfile1.obj).
  7908.  
  7909. I also verified that TLIB was exiting with a 0 on return to dos.  I'm
  7910. baffled.  Anybody uncover "hidden features" with respect to MAKE operate
  7911. as expected.
  7912. ---------------
  7913. Following thread
  7914.  
  7915. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 322P1626 Date: 02/02/90
  7916. From: WARREN SIMONSEN                                       Time: 08:27 pm
  7917.   To: GRANT ELLSWORTH (Rcvd)                                (Read 86 times)
  7918. Subj: R: TURBO C 2.0X MAKE
  7919.  
  7920. Grant, I have not used the Turbo C flavor of make, but based on years of
  7921. UNIX "make"ing consider the following:
  7922.      Make only performs the actions associated with the first dependency
  7923. unless the sources for that action also have subsequent dependencies.
  7924. For example:
  7925.      Absolute object : Relative objectA, Relative objectB, ...
  7926.           Link Relative objects
  7927.      Relative objectA : Source A
  7928.           Assemble SourceA
  7929.      Relative objectB : Source B
  7930.           Assemble SourceB
  7931.      PRINT FILE: SourceA, SourceB
  7932.           Print SourceA, SourceB
  7933. Generally make will follow the chain and perform all needed actions to
  7934. create the Absolute object file, it will NOT however do the printing
  7935. unless the command is entered as "make PRINT FILE" in which case it will
  7936. ONLY do the printing.
  7937.      From the example given in your message my guess is that it will only
  7938. check the first condition because the other conditions are not dependent
  7939. or needed by the first condtion.
  7940. ---------------
  7941. ** Current thread: TURBO C 2.0X MAKE
  7942.  
  7943. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 323F2205 Date: 02/03/90
  7944. From: GRANT ELLSWORTH (Leader)                              Time: 11:36 am
  7945.   To: WARREN SIMONSEN (Rcvd)                                (Read 85 times)
  7946. Subj: R: TURBO C 2.0X MAKE
  7947.  
  7948. Warren, Since filing my original msg, I've found that your discription is
  7949. about 75% right on.   I didn't read the BI dox carefully (again) and it
  7950. had been something like 2 yrs since I last used BI's make --- stepping
  7951. into the same snakepit.
  7952.  
  7953. I expected BI's make to behave like M$'s make, which I half-understand.
  7954. In M$'s MAKE, one can specify a "do it all the time" rule by omitting
  7955. dependencies.  And the MAKE file is processed sort-of linearly - begin to
  7956. end - examining the rules in the order found in the make file.
  7957.  
  7958. On the other hand, BI's MAKE, play a game something like you describe,
  7959. except that the PRINT_FILE: rule in your example will NEVER be exercised
  7960. unless it is 1st triggered via the "absolute object" in your example.
  7961. ALso, as in your example, BI's MAKE requires that the "global" or
  7962. governing rule be stated FIRST --- not at the end, as in M$ Make.
  7963.  
  7964. As in the UNIX-like MAKE you describe, BI's MAKE will execute the rule
  7965. you specify via the command-line.
  7966.  
  7967. Thanks for the reply.   Maybe I'll remember the BI MAKE rules this time,
  7968. so I won't step into the same snakepit of senile forgetfulness again.
  7969.  
  7970. Grant
  7971. ---------------
  7972. ** Current thread: TURBO C 2.0X MAKE
  7973.  
  7974. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 32BE2208 Date: 02/07/90
  7975. From: WARREN SIMONSEN                                       Time: 10:36 am
  7976.   To: GRANT ELLSWORTH (Rcvd)                                (Read 85 times)
  7977. Subj: R: TURBO C 2.0X MAKE
  7978.  
  7979. I wish it were so simple as to resolve not to forget what we learn !  It
  7980. seems that we must either become a snob about tools and languages so as
  7981. to remember a smaller set of information or be resigned to relearning
  7982. things from time to time.
  7983. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  7984.  
  7985. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 322P3585 Date: 02/02/90
  7986. From: JOHN ABATTE                                           Time: 08:59 pm
  7987.   To: ALL                                                   (Read 86 times)
  7988. Subj: PRO-C PACKAGE
  7989.  
  7990.  
  7991.  
  7992.       I'd like to get some information on a package called Pro-C, by
  7993. Vestronix. I haven't seen any reviews of it anywhere, so I'd like to
  7994. hear from anyone who's had any experience with it firsthand. Things
  7995. like, what are its capabilities, limitations, ease of use, etc, etc.
  7996.  
  7997.       Any comments or criticisms would be appreciated also. I've seen it
  7998. advertised lately for $299.00 from the Programmers' Connection, and at
  7999. that price it sounds to good (based on ad copy) to be true.
  8000.  
  8001.       Thanks in advance for any feedback..................John.
  8002.  
  8003.  
  8004.  
  8005. ---------------
  8006.  
  8007. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 32A23240 Date: 02/06/90
  8008. From: BANCROFT SCOTT                                        Time: 02:54 am
  8009.   To: GRANT ELLSWORTH (Rcvd)                                (Read 78 times)
  8010. Subj: PORTING FROM ANSI C TO PRE-ANSI C
  8011.  
  8012. Do you know of a utility which will take a C program which is written
  8013. according to the draft ANSI C standard and convert it to pre-ANSI C
  8014. suitable for being compiled by, say, the UNIX V  C compiler?
  8015. ---------------
  8016. Following thread
  8017.  
  8018. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 32FR0452 Date: 02/11/90
  8019. From: GRANT ELLSWORTH (Leader)                              Time: 10:07 pm
  8020.   To: BANCROFT SCOTT (Rcvd)                                 (Read 83 times)
  8021. Subj: R: PORTING FROM ANSI C TO PRE-ANSI C
  8022.  
  8023. No, I have never see or heard tell of a translator which reverses
  8024. direction from ANSI-C to pre-Ansi-C.  Do you see a long term need for one?
  8025. Or are you dealing with a short-term problem where manual translation is a
  8026. painful time-consuming pain in the tail?  Grant
  8027. ---------------
  8028. ** Current thread: PORTING FROM ANSI C TO PRE-ANSI C
  8029.  
  8030. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 32GL2138 Date: 02/12/90
  8031. From: BANCROFT SCOTT                                        Time: 05:35 pm
  8032.   To: GRANT ELLSWORTH (Rcvd)                                (Read 80 times)
  8033. Subj: R: PORTING FROM ANSI C TO PRE-ANSI C
  8034.  
  8035. At Open Systems Solutions, we wrote an ASN.1 (OSI presentation layer)
  8036. compiler using ANSI-C.  This was a good idea, since we were able to port
  8037. from Microsoft C on the PC to a SUN/4 work station, to IBM MVS.  All with
  8038. less than an hour or so to accomodate the strictness with which the
  8039. various compilers enforce C.
  8040.  
  8041. The problem that we have run into is that on some systems, e.g. VAX/VMS,
  8042. we do not have an ANSI-C compiler.  As such, we either have to port the
  8043. Free Software Foundation GNU ANSI-C compiler to these platforms, or we
  8044. have to convert the ASN.1 compiler to K&R C.  We are looking at both
  8045. possibilities.
  8046.  
  8047. We have found out, through CAIP at Rutgers University, that there is a
  8048. 'Protoizer' which is capable of converting from ANSI C to K&R and visa
  8049. versa; from ANSI C to C++ and visa versa.  We are pursuing the use of
  8050. this tool.  I have no idea as yet as to how good a job it is capable of
  8051. doing.
  8052. ---------------
  8053. ** Current thread: PORTING FROM ANSI C TO PRE-ANSI C
  8054.  
  8055. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 32GM2230 Date: 02/12/90
  8056. From: GRANT ELLSWORTH (Leader)                              Time: 06:37 pm
  8057.   To: BANCROFT SCOTT (Rcvd)                                 (Read 79 times)
  8058. Subj: R: PORTING FROM ANSI C TO PRE-ANSI C
  8059.  
  8060. Hmmm... A preprocessor which lets you do: K+R <--->ANSI_C<--->C++, eh?
  8061. That's gotta be one heck of a handy tool.  Leave msgs with further
  8062. comments as you find out how good (or bad) it is.   What do you know
  8063. of it now? (Vendor, how to get copy, price, etc..)?  Grant
  8064. ---------------
  8065. ** Current thread: PORTING FROM ANSI C TO PRE-ANSI C
  8066.  
  8067. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 32K11620 Date: 02/16/90
  8068. From: BANCROFT SCOTT                                        Time: 12:27 am
  8069.   To: GRANT ELLSWORTH (Rcvd)                                (Read 77 times)
  8070. Subj: R: PORTING FROM ANSI C TO PRE-ANSI C
  8071.  
  8072. The following are excerpts from the documentation of the porting tool:
  8073.  
  8074.      Protoize aids in the conversion of K&R C source  code  files
  8075.      to  ANSI C source code files with function prototypes.  This
  8076.      conversion is useful for eliciting more  complete  interface
  8077.      checking  from ANSI C compilers, or as a preliminary step in
  8078.      the conversion of C programs to C++.
  8079.  
  8080.      Protoize is designed to be used in conjunction with the  GNU
  8081.      C compiler.  The GNU C compiler does preliminary information
  8082.      gathering about functions by analyzing the files to be  con-
  8083.      verted.   The GNU C compiler may be invoked automatically as
  8084.      a result of running protoize so it is important to  have  it
  8085.      properly installed before attempting to convert source files
  8086.      via protoize.
  8087.  
  8088.      Protoize actually has two primary functions.  First, It con-
  8089.      verts existing function declarations and definitions to pro-
  8090.      totype form.  Second,  for  cases  in  which  functions  are
  8091.      called before they have been declared (i.e. points of impli-
  8092.      cit function declarations), protoize can  be  instructed  to
  8093.      insert  new  prototype  style function declarations into the
  8094.      source code.  For implicit function  declarations,  protoize
  8095.      can either insert the new (explicit) function declaration at
  8096.      the very beginning of the block which contains the  implicit
  8097.      declaration,  or  (at  the  user's  option)  these  explicit
  8098.      declarations can be inserted near the  tops  of  the  source
  8099.      files  where the implicit declarations occurred.  The inser-
  8100.      tion of these new (explicit) function declarations (by  pro-
  8101.      toize)  assures that all function calls in your source files
  8102.      will be checked for the correct number and types of  parame-
  8103.      ters during subsequent compilations.
  8104.  
  8105.      Protoize supports the conversion of  both  large  and  small
  8106.      systems  of  C  source code to prototype form.  Protoize can
  8107.      perform the conversion of an  entire  program  in  one  non-
  8108.      interactive step.
  8109.  
  8110.      Protoize is able to convert entire systems of C source  code
  8111.      because  it  knows  how to use information (gleaned by the C
  8112.      compiler) from one source file to convert  function  defini-
  8113.      tions  and declarations in that same source file or in other
  8114.      source files (as required).
  8115.  
  8116.      -C   C++ conversion mode.   Normally,  protoize  writes  its
  8117.           (converted)  output  files  back  to  files of the same
  8118.           names as the original (unconverted)  input  files.   In
  8119.           C++ conversion mode, after each output file is written,
  8120.           a check is made to see if the given output file  has  a
  8121.           .c suffix.  If it does, then the given file is renamed,
  8122.           and its suffix is changed to .C. This makes the  output
  8123.           file  acceptable as a C++ input file for either the GNU
  8124.           C++ compiler or for the Cfront translator.
  8125.  
  8126.      It is naive to assume that the conversions performed by pro-
  8127.      toize  are  sufficient  to  make your source code completely
  8128.      compatible with ANSI C or C++.  The automatic conversion  of
  8129.      your  source  files  via protoize is only one step (albeit a
  8130.      big one) towards full conversion.   A  full  conversion  may
  8131.      also require lots of editing "by hand".
  8132.  
  8133.      Protoize only converts  function  declarations  and  defini-
  8134.      tions.   No  conversion of types (such as function types and
  8135.      pointer-to-function types) contained in  typedef  statements
  8136.      is attempted.  These must be converted manually.
  8137.  
  8138.      Currently, protoize makes no attempt to convert declarations
  8139.      of pointer to function types, variables, or fields.
  8140.  
  8141.      Currently, varargs functions  definitions  and  declarations
  8142.      must  be converted by hand to use the stdarg convention.  It
  8143.      is possible that a subsequent version of protoize will  make
  8144.      some attempt to do these conversions automatically.
  8145.  
  8146. As you see, the stuff about converting to C++ is not great.
  8147.  
  8148. There is a second half to this tool, name Unprotoize.  It does the inverse
  8149. of the operation that Protoize does.  If you need additional information
  8150. on it I can provide it.
  8151.  
  8152. In case you are not familiar with the gcc C compiler, it is a product of
  8153. the Free Software Foundation.  As the company name implies, it is a free
  8154. product.  I does a fairly decent job of supporting ANSI C, but needs to
  8155. be improved (relative to Microsoft C or C/370 on IBM MVS).  With very few
  8156. exceptions, I find gcc to be very reliable (although every now and then
  8157. a bug-laden version is released).
  8158. ---------------
  8159. ** Current thread: PORTING FROM ANSI C TO PRE-ANSI C
  8160.  
  8161. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 32LD1998 Date: 02/17/90
  8162. From: GRANT ELLSWORTH (Leader)                              Time: 09:33 am
  8163.   To: BANCROFT SCOTT (Rcvd)                                 (Read 76 times)
  8164. Subj: R: PORTING FROM ANSI C TO PRE-ANSI C
  8165.  
  8166. Please forgive my ignorance,,, but, while I have seen the name "Free Soft-
  8167. ware Foundation", I don't really know anything about it.  What is the
  8168. contact address/bbs-number/voice-number?  How might I obtain a copy of the
  8169. PROTOIZE/UNPROTO software?  What is the "gcc" compiler and how does one
  8170. get a copy?
  8171.  
  8172. Thanks very much for the elaborate copy of the PROTO/UNPROTO feature
  8173. summary.  It was very informative.
  8174.  
  8175. The summary you provided was sufficient enough to allow us to reasonably
  8176. infer the probable operation of the UNPROTO operation.
  8177.  
  8178. HOwever, it would be very helpful if you could consolditate into 1 zipfile
  8179. the protoize and unprotoize descriptions and upload it to the Mahoney and
  8180. Unix collections for access by a wider audience.
  8181.  
  8182. From your own experiences, I gather that there may be a wider interest
  8183. in this problem (K&R C <--> Ansi-C <---> C++) than I had previously
  8184. assumed --- and our colleagues here would welcome the info.
  8185.  
  8186. Grant
  8187. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  8188.  
  8189. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 32AH1703 Date: 02/06/90
  8190. From: KEVIN MENNINGEN                                       Time: 01:28 pm
  8191.   To: GRANT ELLSWORTH (Rcvd)                                (Read 90 times)
  8192. Subj: TURBO C LINKING
  8193.  
  8194. Grant,
  8195.     I am doing a project for school in Turbo C.  The project is split
  8196. up into six different files, all dependent upon global variables and
  8197. declarations contained in GLOBAL.H.  The program compiles fine, but
  8198. when I link, I get errors saying that global variables in GLOBAL.H are
  8199. duplicated in each of the modules.  fine.  I remove the #include statments
  8200. from each module except one, and I get errors saying variables areπ
  8201. undefined.  How do I get this to go?  I'm using a MAKE file, but it
  8202. does exactly what I want it to do.  Help.
  8203.      --Kevin
  8204. ---------------
  8205. Following thread
  8206.  
  8207. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 32B11870 Date: 02/07/90
  8208. From: GLEN THOMPSON                                         Time: 12:31 am
  8209.   To: KEVIN MENNINGEN (Rcvd)                                (Read 91 times)
  8210. Subj: R: TURBO C LINKING
  8211.  
  8212. Kevin,
  8213.  
  8214. The global variables should only be declared in one place.  The other
  8215. includes should refer to the declared globals.  Check out the use of the
  8216. extern directive.
  8217.  
  8218. i.e.
  8219.  
  8220.      int  global_int ;
  8221.  
  8222.      main() {
  8223.         . . .
  8224.      }
  8225.  
  8226. in next file"
  8227.  
  8228.      extern int global_int;
  8229.  
  8230.      function() {
  8231.        . . .
  8232.      }
  8233.  
  8234.  
  8235. glen
  8236. ---------------
  8237. ** Current thread: TURBO C LINKING
  8238.  
  8239. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 32BG2489 Date: 02/07/90
  8240. From: KEVIN MENNINGEN                                       Time: 12:41 pm
  8241.   To: GLEN THOMPSON (Rcvd)                                  (Read 83 times)
  8242. Subj: R: TURBO C LINKING
  8243.  
  8244. Glen,
  8245.     Thanks for the answer.  It worked.  Us Pascal freaks really have
  8246. a tough time with C sometimes, because we are so used to having only one
  8247. road to the destination that a fork in the road is somewhat baffling.
  8248.     It also didn't help that UNIX doesn't require the extern, it simply
  8249. takes the declarations from GLOBAL.H and says "fine."  Oh, well.
  8250.       --Kevin
  8251. ---------------
  8252. ** Current thread: TURBO C LINKING
  8253.  
  8254. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 32FR1263 Date: 02/11/90
  8255. From: GRANT ELLSWORTH (Leader)                              Time: 10:21 pm
  8256.   To: KEVIN MENNINGEN (Rcvd)                                (Read 88 times)
  8257. Subj: R: TURBO C LINKING
  8258.  
  8259. Kevin,  YOu'll have to do something like the following:
  8260.  
  8261. 1.  Decide which of the six modules you want the global variables
  8262.     to be "local" to --- best bet is your "main()" section
  8263.  
  8264. 2.  In your GLOBAL.H file, make ALL the global variables 'extern'
  8265.  
  8266.     e.g.
  8267.  
  8268.    extern int global_var_1;
  8269.  
  8270. 3.  In the very start of your GLOBAL.H file add the following statements
  8271.  
  8272.     #ifdef __MAIN_ROUTINE__
  8273.     #define extern
  8274.     #endif
  8275.  
  8276. 4.  Restore the #include statements to all your program files
  8277.  
  8278. 5.  Add the following statement to your main program (or whichever
  8279.     routine you decided you wanted to make your global variables local
  8280.     to --- defined in)
  8281.  
  8282.     #define __MAIN_ROUTINE__
  8283.  
  8284.     insert this statement BEFORE the
  8285.  
  8286.     #include "globals.h"
  8287.  
  8288.     statement
  8289.  
  8290. Now, after you do this, reason out for yourself the underlying logic and
  8291. rationale for the above approach.  I could have written the theory and
  8292. left
  8293. the encoding to the reader ... but this one was a little easier to encode
  8294. than to accurately and BRIEFLY explain the theory.   Hope this helps.
  8295.  
  8296. Grant
  8297. ---------------
  8298. ** Current thread: TURBO C LINKING
  8299.  
  8300. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 32IK1124 Date: 02/14/90
  8301. From: KEVIN MENNINGEN                                       Time: 04:18 pm
  8302.   To: GRANT ELLSWORTH (Rcvd)                                (Read 76 times)
  8303. Subj: R: TURBO C LINKING
  8304.  
  8305. Grant,
  8306.    From your description, you basically tell GLOBAL.H to define all
  8307. variables as EXTERN, except in the main file, where you define the keyword
  8308. extern to be nothing, thus effectively declaring the variables normally.
  8309. Basically, I did this manually, but your method is a neat trick.  Thank
  8310. you!
  8311.      --Kevin
  8312. ---------------
  8313. ** Current thread: TURBO C LINKING
  8314.  
  8315. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 32IP3259 Date: 02/14/90
  8316. From: GRANT ELLSWORTH (Leader)                              Time: 08:54 pm
  8317.   To: KEVIN MENNINGEN (Rcvd)                                (Read 94 times)
  8318. Subj: R: TURBO C LINKING
  8319.  
  8320. Kevin, You got the point quite rightly.  The first time I stumbled into
  8321. the problem,  I solved it with some manual (redundant) coding as well.
  8322. All was cool ... until I had to make a bunch of changes affecting the
  8323. globals.  At which point, I decided to find a far less painful way to
  8324. make future global changes.   Part of the learning experience.  Grant
  8325. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  8326.  
  8327. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 32BN2378 Date: 02/07/90
  8328. From: DENNIS DODSON                                         Time: 07:39 pm
  8329.   To: ALL                                                   (Read 83 times)
  8330. Subj: POINTER QUESTION
  8331.  
  8332. How can I do a compare to determine if the pointer '*prog' is equal to
  8333. the string "pmm" in the following sample source code:
  8334.  
  8335. main()
  8336. {
  8337.  .
  8338.  .
  8339. }
  8340.  
  8341. some_funct(prog)
  8342. char *prog;
  8343. {
  8344.     if (strncmp(*prog, "pmm", 3) == 0)    /* is this correct ??? */
  8345.         do_something();
  8346. }
  8347.  
  8348. Please help, I'm not too sharp with pointers.....
  8349. ---------------
  8350. Following thread
  8351.  
  8352. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 32BP1931 Date: 02/07/90
  8353. From: TOM FRANK                                             Time: 08:32 pm
  8354.   To: DENNIS DODSON (Rcvd)                                  (Read 78 times)
  8355. Subj: R: POINTER QUESTION
  8356.  
  8357. Dennis,
  8358.  
  8359. You don't need the "*" in the strncmp - in fact it is wrong. *prog is the
  8360. first character while prog is a pointer to a char - which is exactly what
  8361. a string is - a pointer to a char (or sequence of chars).  If your
  8362. compiler supports prototypes and full checking, turn it on - you would
  8363. then get warnings when you have conflictingusages.
  8364.  
  8365. Tom
  8366. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  8367.  
  8368. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 32CP0431 Date: 02/08/90
  8369. From: DALE REID                                             Time: 08:07 pm
  8370.   To: ALL                                                   (Read 93 times)
  8371. Subj: TEMPNAM PROBLEM
  8372.  
  8373. I'm trying to learn C by getting an example program to
  8374. work on my machine. Earlier some kind souls have helped
  8375. me with cursor positioning, and that has been of help.  Now
  8376. I'm stymied with this problem....
  8377.  
  8378. I want to be able to call the below routine time and time
  8379. again, each time the program will automatically name the
  8380. new "gif" file for me.  This portion of code is partially
  8381. the working stuff, which always called the spawn with
  8382. "sat.gif" as a default.  I attempted to add the code to
  8383. look to see if previous versions of the name were out
  8384. there, using "sat" as the base, intending to bump the
  8385. name one character at at time, and string concatenating
  8386. ".gif" onto the end.  Strangely, this code below partially
  8387. works.  It will come back with "sat2", "sat3", etc upon
  8388. repeated calls.  This is despite my ignorance in calling
  8389. it with no extention (CAN you call it with an extention
  8390. such as giving it the kernal "sat.gif" and having it
  8391. cough up "sat1.gif", "sat2.gif" etc. over and over?)
  8392.  
  8393. /* ************************************ */
  8394.  
  8395. void    Gifit( void )
  8396. {
  8397.         char    *args[3];
  8398.         char *tfilename;
  8399.  
  8400.         tfilename = tempnam(NULL,"sat");
  8401.             if (tfilename == NULL);
  8402.             {
  8403.               perror("tempnam failed");
  8404.             }
  8405.             strcat(tfilename,".gif");
  8406.  
  8407.         args[0] = "aptgif.exe";
  8408.         args[1] = tfilename;
  8409.         args[2] = NULL;
  8410.         spawnv(P_WAIT,"aptgif.exe",args);
  8411.         beep();
  8412.  
  8413. }
  8414.  
  8415. /* ************************************ */
  8416.  
  8417. Is there a better way?  I've thought of manufacturing
  8418. the file name, calling an open function to see if I get an
  8419. error, if so, close the file, bump the name, and call again.
  8420. Sort of a klutzy way of doing it, but would incorporate the
  8421. required feature although I haven't tried it yet in hopes
  8422. that the gurus here could take me once again by the hand
  8423. and lead my from this abyss.  Somehow the whole string
  8424. function stuff in C seems less elegant that Basic and I'm
  8425. disappointed it is so cumbersome.  For instance the strcat()
  8426. function requires that you allow it to modify the first argument.
  8427. That requires creating the modifiable string by copying from a
  8428. pattern, and then calling strcat(), rather than the more
  8429. intuative function of having it return a pointer to a new
  8430. string concatenated from two separate, unmodified-by-the-function
  8431. strings.  But I guess they didn't ask me when the designed the
  8432. string functions......  Seriously, folks, any help would be
  8433. appreciated.  Dale
  8434.  
  8435. s
  8436.  
  8437. ---------------
  8438. Following thread
  8439.  
  8440. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 32LF1365 Date: 02/17/90
  8441. From: JOHN HEIM                                             Time: 11:22 am
  8442.   To: DALE REID (Rcvd)                                      (Read 72 times)
  8443. Subj: R: TEMPNAM PROBLEM
  8444.  
  8445. You don't have to try to open a file to see if it exists.  There is a
  8446. function called access that allows you to check if a file exists.
  8447.  
  8448. char    fname[13]
  8449. int     fnbr = 0
  8450.  
  8451. do {
  8452.      sprintf(fname, "sat%05hd.gif", fnbr);
  8453.  
  8454. } while (access(fname, 0) == 0);
  8455.  
  8456. This will check for files. with names like sat00000.gif, sat00001.gif,
  8457. sat00002.gif, etc.  Which leads me to your question about strings in C.
  8458. No C isn't the greatest at string manipulation but the sprintf function is
  8459. alot easier to use than combinations of strcpy and strcat.  I've heard
  8460. that it not as efficient though.  If you're not too concerned about the
  8461. size of the object code I'd use sprintf.
  8462.  
  8463. BTW, when the loop above exits, fname will be the next available file
  8464. name.
  8465.  
  8466. John
  8467.  
  8468. PS.  There's supposed to be semi-colons at the end of lines 4 & 5 of
  8469. course.  The edit function won't let me add them.
  8470. ---------------
  8471. ** Current thread: TEMPNAM PROBLEM
  8472.  
  8473. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 32LR1606 Date: 02/17/90
  8474. From: DALE REID                                             Time: 10:26 pm
  8475.   To: JOHN HEIM (Rcvd)                                      (Read 83 times)
  8476. Subj: R: TEMPNAM PROBLEM
  8477.  
  8478. Tank yew, tank yew... I'll look into it tonight.  Dale
  8479. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  8480.  
  8481. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 32DD1057 Date: 02/09/90
  8482. From: ROB SUTSCHEK                                          Time: 09:17 am
  8483.   To: ALL                                                   (Read 99 times)
  8484. Subj: C TUTOR PROGRAMS
  8485.  
  8486. Does anyone know of a good C tutor program available in the Mahoney
  8487. Collection.  I have tried to scan for one... but well...
  8488. I bought a book and disks called LearnC Now (eeeeyons ago)!  Any comments
  8489. will be appreciated!
  8490. -rob
  8491. ---------------
  8492. Following thread
  8493.  
  8494. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34CE0028 Date: 04/08/90
  8495. From: MARK STOLOWSKI                                        Time: 10:00 am
  8496.   To: ROB SUTSCHEK (Rcvd)                                   (Read 80 times)
  8497. Subj: R: C TUTOR PROGRAMS
  8498.  
  8499.  > Does anyone know of a good C tutor program available in the Mahoney
  8500.  > Collection.
  8501.  
  8502. Rob, I hope this is better late than never. There is a pretty good Turbo C
  8503. tutor in the Mahony collection. The file is TUR-C-TU.ZIP. I'm just
  8504. starting to try my hand at C myself and since we have Borlunds Turbo C at
  8505. work I figure I might as well go that route. Good luck, maybe we can
  8506. compare notes. Hope this was a help.
  8507. Mark
  8508. ---------------
  8509. ** Current thread: C TUTOR PROGRAMS
  8510.  
  8511. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34CF0038 Date: 04/08/90
  8512. From: MARK STOLOWSKI                                        Time: 11:00 am
  8513.   To: ROB SUTSCHEK (Rcvd)                                   (Read 78 times)
  8514. Subj: R: C TUTOR PROGRAMS
  8515.  
  8516. P.S. I stumbled upon a C tutor in the PC-SIG collection. Files 816 & 817.
  8517. Mark
  8518. ---------------
  8519. ** Current thread: C TUTOR PROGRAMS
  8520.  
  8521. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34DK1670 Date: 04/09/90
  8522. From: ROB SUTSCHEK                                          Time: 04:27 pm
  8523.   To: MARK STOLOWSKI (Rcvd)                                 (Read 75 times)
  8524. Subj: R: C TUTOR PROGRAMS
  8525.  
  8526. Thanks-
  8527. I think I will download them tonight.
  8528. -
  8529. Since writing that note (with NO response), I have stumbled across a few
  8530. tutor programs, but I could not tell what was good, and what was (garbage)
  8531. stuck!
  8532. -
  8533. Thanks... I'll keep in touch.
  8534. Rob
  8535. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  8536.  
  8537. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 32GL1855 Date: 02/12/90
  8538. From: JAMES SAVAGE                                          Time: 05:30 pm
  8539.   To: ALL                                                   (Read 74 times)
  8540. Subj: LEARNING "C"
  8541.  
  8542. Message CC'd to:
  8543.      ALL
  8544.      GRANT ELLSWORTH
  8545.  
  8546.   I'm looking for a good book or ? to get me started programming in
  8547. C in a Macintosh environment.
  8548. ---------------
  8549. Following thread
  8550.  
  8551. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 32GM1914 Date: 02/12/90
  8552. From: GRANT ELLSWORTH (Leader)                              Time: 06:31 pm
  8553.   To: JAMES SAVAGE (Rcvd)                                   (Read 80 times)
  8554. Subj: R: LEARNING "C"
  8555.  
  8556. I haven't seen a "C" / Macintosh book.  But, I DO have 2 suggestions:
  8557.  
  8558. 1.  Earlier in this conference topic, some other correspondents asked
  8559.     about books to assist in learning C ... and frequently the msg
  8560.     subject was the same as yours.   One correspondent, however, left
  8561.     message asking question: "C the summer go by" or something to that
  8562.     effect
  8563.  
  8564.    Do a search on the subjects in this topic ... I left one of these
  8565.     writers a msg with 4 or so books / titles
  8566.  
  8567. 2.  Check out hte generic Macintosh-oriented books on the bookstore
  8568.     shelves (B. Dalton, etc..)
  8569.  
  8570.     I wouldn't be surprised if some of them did have some c programming
  8571.     examples specifically oriented towards Macintosh programming
  8572.  
  8573. Leave msg if you can't find the other exchanges in the confernece/topic.
  8574. I'll re-assemble the book/title list offline and upload it again.  Grant
  8575. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  8576.  
  8577. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 32JR0759 Date: 02/15/90
  8578. From: GERALD NOVAK                                          Time: 10:12 pm
  8579.   To: ALL                                                   (Read 63 times)
  8580. Subj: C COURSE
  8581.  
  8582. I have some time and want to start learning C. I have experience with
  8583. Dbase/Fox Pro/Fox Base/ QuickSilver/Basic/etc. I have Microsoft C complete
  8584. but haven't really installed it yet (never had the time).
  8585.     Is there a course offered anywhere in Milwaukee - especially at night?
  8586. Any of the Universities or user groups help with that?
  8587.    I'm new to the city ....
  8588.     Thanks!
  8589.         Jer
  8590. ---------------
  8591.  
  8592. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 32K11651 Date: 02/16/90
  8593. From: OTTO PORTER                                           Time: 12:27 am
  8594.   To: GRANT ELLSWORTH (Rcvd)                                (Read 70 times)
  8595. Subj: FPRINTF
  8596.  
  8597. Grant,
  8598. It's been awhile since Ive visited here but I have a little questtion
  8599. about a problem I'm having.
  8600. I am opening a file with FOPEN and setting the file pointer to the
  8601. end of the file with FSEEK.  At this point I am trying to append
  8602. some text records in binary to the end of the file. They are each
  8603. 80 bytes long.  The strings are being pulled from a structure
  8604. in memory which is an array of the records.  That is probably
  8605. irrevalant.  The first write to the file with FPRINTF results
  8606. in garbage but the strings go in alright from then on.  All
  8607. the strings are written to the file but there is a bunch of
  8608. garbage after the end of the original file and the new strings.
  8609.  
  8610. A friend suggests using the low level functions to avoid buffering
  8611. but I am not ready to believe that the high level functions WILL
  8612. NOT work properly. Or that I am not making an error. Is there
  8613. a timing factor with using FSEEK.  I can't escape the feeling that
  8614. I am missing something basic here.
  8615.  
  8616. Thanks in advance.  Otto...
  8617. ---------------
  8618. Following thread
  8619.  
  8620. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 32LD2863 Date: 02/17/90
  8621. From: GRANT ELLSWORTH (Leader)                              Time: 09:47 am
  8622.   To: OTTO PORTER (Rcvd)                                    (Read 70 times)
  8623. Subj: R: FPRINTF
  8624.  
  8625. Otto, The use of fopen() and fseek() (or lseek()) is correct.  However,
  8626. I don't understand why you would be using fprintf() to write the binary
  8627. stuff --- frpintf(), a kin to printf(), is used to write formatted text
  8628. output where you use format control codes to format an output string.
  8629. Seems to me that the function you want to use is fwrite() --- fwrite() is
  8630. ideally suited to your need to write fixed-length unformatted units to
  8631. your file.  I don't think of fwrite() as a "low level" function since it
  8632. seems to be part of the stdio.h set in all C compilers I've been exposed
  8633. to.  The fwrite() function description goes approximately like this:
  8634.  
  8635.   int fwrite(char * buffer, int size_to_write, int number_of_writes,
  8636.          FILE * stream);
  8637.  
  8638. and it returns the number of units of size_to_write actually written (or
  8639. an indication for error, etc.).
  8640.  
  8641. This may be the function you "skipped over".  Its reverse is fread().
  8642.  
  8643. Grant
  8644. ---------------
  8645. ** Current thread: FPRINTF
  8646.  
  8647. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 32Q20768 Date: 02/21/90
  8648. From: OTTO PORTER                                           Time: 02:12 am
  8649.   To: GRANT ELLSWORTH (Rcvd)                                (Read 85 times)
  8650. Subj: R: FPRINTF
  8651.  
  8652. Thanks for the come back.  These records ARE formatted in one respect.
  8653. They have to be padded when written to the file.  BTW I finally solved
  8654. my problem by explicitly going to the end of file by using
  8655. (number of records*size of record) with the Fseek.  Just seeking the
  8656. end of file was putting me beyond the last record.
  8657. Thanks again.
  8658. Otto..
  8659. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  8660.  
  8661. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 32NL0858 Date: 02/19/90
  8662. From: MICHAEL MCCLUNE                                       Time: 05:14 pm
  8663.   To: ALL                                                   (Read 81 times)
  8664. Subj: EXEC? FUNC
  8665.  
  8666. I need to know if I may run a batch file after my program
  8667. exits. I have tried some of the exec? functions in QC
  8668. but the program locks when I try to run the batch file.
  8669. I do not wish to pass any command line arguments to the
  8670. batch file. Basically I have been trying exec?("some.bat",NULL);
  8671. but have had no luck.
  8672. A speedy response is appreciated
  8673. Mike
  8674. ---------------
  8675. Following thread
  8676.  
  8677. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 32PF0723 Date: 02/20/90
  8678. From: JOHN HEY                                              Time: 11:12 am
  8679.   To: MICHAEL MCCLUNE (Rcvd)                                (Read 87 times)
  8680. Subj: R: EXEC? FUNC
  8681.  
  8682. I don't think you can EXEC or SPAWN to a batch file.  Maybe you should
  8683. give SYSTEM a try.  In MSC5.1, the syntax is: system(char *filename)
  8684.  
  8685. I suspect this is necessary, since you will need to load another copy of
  8686. command.com in order to execute the batch file.  This is not necessary, of
  8687. course, when you need to exec or spawn a *real* executable file!
  8688.  
  8689. John Hey--
  8690. ---------------
  8691. ** Current thread: EXEC? FUNC
  8692.  
  8693. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 32PJ3276 Date: 02/20/90
  8694. From: STEVEN KEY                                            Time: 03:54 pm
  8695.   To: MICHAEL MCCLUNE (Rcvd)                                (Read 82 times)
  8696. Subj: R: EXEC? FUNC
  8697.  
  8698. Michael,
  8699.  
  8700. I don't use QC, so this may be out of line, butI do know that you will
  8701. need to run a second copy of command.com to run a batch file.  Try
  8702. something like this: exec('command.com','batch.bat'), where batch.bat is
  8703. the name of your batch file.
  8704.  
  8705. Steven
  8706. ---------------
  8707. ** Current thread: EXEC? FUNC
  8708.  
  8709. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 32PM2530 Date: 02/20/90
  8710. From: MICHAEL MCCLUNE                                       Time: 06:42 pm
  8711.   To: JOHN HEY (Rcvd)                                       (Read 88 times)
  8712. Subj: R: EXEC? FUNC
  8713.  
  8714. John
  8715. Darn, I would really like to kill my program and go do something else
  8716. by running a batch file. Essentially I want to keep as much memory
  8717. free as I can. Spose I could overlay but that seems so messy. Save
  8718. mine to disk call something else read mine from disk. You can't think
  8719. of another way to do things?
  8720. Mike
  8721. ---------------
  8722. ** Current thread: EXEC? FUNC
  8723.  
  8724. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 32QL1808 Date: 02/21/90
  8725. From: JOHN HEY                                              Time: 05:30 pm
  8726.   To: MICHAEL MCCLUNE (Rcvd)                                (Read 101 times)
  8727. Subj: R: EXEC? FUNC
  8728.  
  8729. That's a tough one.  The only way I know of to "spawn" to another program
  8730. and do so by "overlaying" the calling program is to use something like
  8731. "Hold Everything", which is a product by South Mountain Software.
  8732. Programmer's Shop sells it.
  8733.  
  8734. Hold Everything works by writing your program to disk (or EMS memory),
  8735. then spawning the desired program, then reloading your program and picking
  8736. up its execution right where it left off.  Pretty neat, huh?  Doing that
  8737. is certainly non-trivial, but Hold Everything seems to work quite well.
  8738.  
  8739. Otherwise, the only way to "fake" it would be to exec to the command
  8740. process, run the batch file, and have the batch file re-execute the
  8741. calling program.  Not very elegant or flexible, I admit
  8742.  
  8743. Good Luck
  8744. John Hey--
  8745. ---------------
  8746. ** Current thread: EXEC? FUNC
  8747.  
  8748. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 32QR0365 Date: 02/21/90
  8749. From: JOHN HEIM                                             Time: 10:06 pm
  8750.   To: MICHAEL MCCLUNE (Rcvd)                                (Read 97 times)
  8751. Subj: R: EXEC? FUNC
  8752.  
  8753. Have you considered running the program from within the batch file.  Then
  8754. when you exited you'd be still in the batch file.  You could set DOS
  8755. error level so you're batch file would know what to do when the program
  8756. terminated.
  8757.  
  8758. John
  8759. ---------------
  8760. ** Current thread: EXEC? FUNC
  8761.  
  8762. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 32QR0809 Date: 02/21/90
  8763. From: GLEN THOMPSON                                         Time: 10:13 pm
  8764.   To: MICHAEL MCCLUNE (Rcvd)                                (Read 98 times)
  8765. Subj: R: EXEC? FUNC
  8766.  
  8767. Mike,
  8768.  
  8769. One way to do it is to start your program with one batch file, have the
  8770. line in the bat file after your program be another bat file.  Your program
  8771. could write that second batch file.  See the example below.
  8772.  
  8773. START.BAT
  8774.    ECHO OFF
  8775.    YOURPROG
  8776.    NEXTBAT
  8777.  
  8778. NEXTBAT.BAT
  8779.    (contents written by YOURPROG)
  8780.  
  8781. To make a looping system, have YOURPROG write out a bat file like:
  8782.    NEXTPROG
  8783.    START
  8784.  
  8785. where NEXTPROG may vary. That way your program can determine the program
  8786. to be run next, free up the memory yet still have control return to it.
  8787. To get out completely, just have the NEXTBAT.BAT file be empty.
  8788.  
  8789. There is a menuing system caled AUTOMAXX that uses a similar principle.
  8790. It is available in the Mahoney collection.
  8791.  
  8792. glen
  8793. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  8794.  
  8795. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 32PR3016 Date: 02/20/90
  8796. From: WARREN SIMONSEN                                       Time: 10:50 pm
  8797.   To: ALL                                                   (Read 88 times)
  8798. Subj: EXTERNAL STRUCTURES
  8799.  
  8800. How do you define a structure as a global while keeping the individual
  8801. pointers to a structure of that type local?  I am using Turbo C (V2.0)
  8802. and I want to define a type of structure that will be used to create
  8803. separate linked lists in each of several functions.
  8804. For example:
  8805.     I would like the following definition to be global:
  8806.             typedef struct{ unsigned *addr_ptr;
  8807.                             char     *data_ptr;
  8808.                           }entry;
  8809.             main ()
  8810.             {
  8811.                     ......
  8812.             }
  8813.    while the following pointers to that type are local to the functions:
  8814.             function1()
  8815.             {
  8816.                 entry *listntry;
  8817.                       ...
  8818.             }
  8819.             function2()
  8820.             {
  8821.                 entry *listptr;
  8822.                        ...
  8823.             }
  8824. Oh yeah, one more thing, the functions are defined in separate files.  I
  8825. have tried every combination of extern with "entry" with "struct" in
  8826. dozens of combinations.  I have scoured the Turbo C manuals and 4 other
  8827. books that talked about Turbo C, but all I get is illegal syntax or
  8828. definition errors.  Is there some magical incantation I have missed or
  8829. am I simply trying to do something that is taboo in C ?
  8830. ---------------
  8831. Following thread
  8832.  
  8833. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 32QL0600 Date: 02/21/90
  8834. From: MICHAEL MCCLUNE                                       Time: 05:10 pm
  8835.   To: WARREN SIMONSEN (Rcvd)                                (Read 106 times)
  8836. Subj: R: EXTERNAL STRUCTURES
  8837.  
  8838. Warren
  8839. Put your structure in a header file and #include it in the
  8840. individual files.
  8841. Mike
  8842. ---------------
  8843. ** Current thread: EXTERNAL STRUCTURES
  8844.  
  8845. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 32QP3513 Date: 02/21/90
  8846. From: WARREN SIMONSEN                                       Time: 08:58 pm
  8847.   To: MICHAEL MCCLUNE (Rcvd)                                (Read 109 times)
  8848. Subj: R: EXTERNAL STRUCTURES
  8849.  
  8850. Well, yes, that does effectively duplicate the structure definition while
  8851. maintaining a central definition, but I don't want duplicates, I want all
  8852. the functions to point to the SAME definition.  Maybe I forgot to state
  8853. that while some of the pointers to this type of structure are to be local
  8854. others are to be global.  I want a linked list that has a starting point
  8855. that is globally recognized, but the functions that add or modify the list
  8856. use local, temporary pointers to accomplish their task.
  8857. ---------------
  8858. ** Current thread: EXTERNAL STRUCTURES
  8859.  
  8860. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 32QR1068 Date: 02/21/90
  8861. From: JOHN HEIM                                             Time: 10:17 pm
  8862.   To: WARREN SIMONSEN (Rcvd)                                (Read 101 times)
  8863. Subj: R: EXTERNAL STRUCTURES
  8864.  
  8865. You can declare entry to be a global then still pass it's address to a
  8866. function.
  8867.  
  8868. typedef struct
  8869. {
  8870.      ....
  8871. } ENTRY;
  8872.  
  8873. ENTRY entry;
  8874.  
  8875. main()
  8876. {
  8877.      funct(&entry);
  8878. }
  8879.  
  8880. funct(ENTRY *locentry)
  8881. {
  8882.      ....
  8883. }
  8884.  
  8885. This pointer to locentry in funct is local.  I'm not sure if this is what
  8886. you're getting at though.  Hope I'm not waisting your time.
  8887.  
  8888. John
  8889. ---------------
  8890. ** Current thread: EXTERNAL STRUCTURES
  8891.  
  8892. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 32SC1668 Date: 02/23/90
  8893. From: STEVE HOVEY                                           Time: 08:27 am
  8894.   To: JOHN HEIM (Rcvd)                                      (Read 98 times)
  8895. Subj: R: EXTERNAL STRUCTURES
  8896.  
  8897. to set up a structure u can use anywhere forget the typedef.. use this
  8898. instead
  8899.  
  8900. struct entry {
  8901.         name[81];
  8902.         address[21];
  8903.          .......
  8904.         };
  8905.  
  8906. main()
  8907. {
  8908.    struct entry entry[20]  /* if u want an array of entry structures */
  8909.  .......
  8910.   ........
  8911. }
  8912.  
  8913. secondroutine()
  8914. {
  8915.   struct entry entry[21]; /* both of these entry structs are local
  8916.                              to their routines... u can pass a struct
  8917.                              and its information like this */
  8918.   thirdroutine(&entry);
  8919.   .....
  8920. }
  8921.  
  8922. thirdroutine( struct entry *entry)
  8923. {
  8924.   ....
  8925.            /* now when u do sumthin to a field in entry it will return
  8926.               the changes to secondroutine but NOT to main */
  8927.   .....
  8928.  }
  8929.  
  8930. if this dont answer it them i dont know what is being asked
  8931. ---------------
  8932. ** Current thread: EXTERNAL STRUCTURES
  8933.  
  8934. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 32SN2235 Date: 02/23/90
  8935. From: MICHAEL MCCLUNE                                       Time: 07:37 pm
  8936.   To: WARREN SIMONSEN (Rcvd)                                (Read 91 times)
  8937. Subj: R: EXTERNAL STRUCTURES
  8938.  
  8939. Warren
  8940. Use this definition for your struct
  8941. typedef struct entry{
  8942.      int some;
  8943.      char thing;
  8944. };     /* no memory is allocated for this struct */
  8945.        /* put this in a header file */
  8946.        /* which must appear in any file using this def */
  8947. then in your main file declare a global var
  8948. entry global;
  8949. main(){
  8950. }      /* now you have one global var which may be ref'd */
  8951. in your next file #include the def of the struct.
  8952. file_2()
  8953. {
  8954.      entry local;     /* space is allocated and only visible */
  8955.                       /* to this func */
  8956. }
  8957. no duplicates are made of the struct and each func has its own
  8958. copy of the struct. If you want to use the global def global
  8959. declare it extern in another file so.
  8960. extern entry global;
  8961. file_3(){
  8962. }      /* compiler looks up the def in the header file */
  8963.        /* finds it and assumes that the global var is */
  8964.        /* defined another file */
  8965. by the way your def would create dups of the struct because
  8966. you have declared a var of that struct notice the difference
  8967. typedef struct {
  8968.      ...
  8969.      ...
  8970. }yours;     /* memory allocated and you don't want this */
  8971.  
  8972. ---------------
  8973. ** Current thread: EXTERNAL STRUCTURES
  8974.  
  8975. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 32SS3106 Date: 02/23/90
  8976. From: WARREN SIMONSEN                                       Time: 11:51 pm
  8977.   To: MICHAEL MCCLUNE (Rcvd)                                (Read 88 times)
  8978. Subj: R: EXTERNAL STRUCTURES
  8979.  
  8980. Thank you.  Your response was directly to the point.  After my last
  8981. message it occurred to me that the definition of the structure should
  8982. not require assigning memory and that the actual assignment of memory
  8983. should be able to be treated just like any other variable.  The point
  8984. I was missing was that following the last } with the structure name
  8985. actually assigned the memory.  Consider a very small area of ignorance
  8986. to have been eliminated!
  8987. ---------------
  8988. ** Current thread: EXTERNAL STRUCTURES
  8989.  
  8990. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 32T10079 Date: 02/24/90
  8991. From: WARREN SIMONSEN                                       Time: 12:01 am
  8992.   To: JOHN HEIM (Rcvd)                                      (Read 87 times)
  8993. Subj: R: EXTERNAL STRUCTURES
  8994.  
  8995. I never consider any response a waste of my time.  Your idea is correct
  8996. to a point, but consider Michael Mcclune's message of 2/23/90 to me.
  8997. The point I was missing was that the label after the last } in the struct
  8998. definition actually assigned memory.
  8999. ---------------
  9000. ** Current thread: EXTERNAL STRUCTURES
  9001.  
  9002. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 32TC1207 Date: 02/24/90
  9003. From: MICHAEL MCCLUNE                                       Time: 08:20 am
  9004.   To: WARREN SIMONSEN (Rcvd)                                (Read 85 times)
  9005. Subj: R: EXTERNAL STRUCTURES
  9006.  
  9007. Warren
  9008. Sometimes all it takes is anothers perspective of a problem and I
  9009. should have been more specific in my first response, ignorance
  9010. on my part. We each learned something.
  9011. Your welcome
  9012. Mike
  9013. ---------------
  9014. ** Current thread: EXTERNAL STRUCTURES
  9015.  
  9016. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 333H2034 Date: 03/03/90
  9017. From: JOHN HEIM                                             Time: 01:33 pm
  9018.   To: WARREN SIMONSEN (Rcvd)                                (Read 83 times)
  9019. Subj: R: EXTERNAL STRUCTURES
  9020.  
  9021. I dont think the label after the last } in a struct definition assigns
  9022. memory if its a typedef.
  9023.  
  9024. ie ...
  9025. struct {
  9026.    ...
  9027. } label;  /* This uses up memory */
  9028.  
  9029. typedef struct {
  9030.  ...
  9031. } LABEL;  /* This does not use up memeory */
  9032.  
  9033. Maybe with the typedef a little memory is used to keep the definition of
  9034. the type but no structure is allocated.
  9035.  
  9036. John
  9037. ---------------
  9038. ** Current thread: EXTERNAL STRUCTURES
  9039.  
  9040. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 335R1259 Date: 03/05/90
  9041. From: WARREN SIMONSEN                                       Time: 10:21 pm
  9042.   To: JOHN HEIM (Rcvd)                                      (Read 75 times)
  9043. Subj: R: EXTERNAL STRUCTURES
  9044.  
  9045. So much for simple answers....  I guess I'll have to do some experimenting
  9046. when I get get through all the "by the way" projects that have gotten in
  9047. the way since I left the first question.  Thanks for your input.
  9048. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  9049.  
  9050. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 32QJ1750 Date: 02/21/90
  9051. From: KEAN JOHNSTON                                         Time: 03:29 pm
  9052.   To: ALL                                                   (Read 82 times)
  9053. Subj: R-TREE HELP PLEASE?
  9054.  
  9055. Ok - Exec-PC is my last hope for a solution to my problem. However, before
  9056. I launch into a detailed explaination of the problem, if anyone can help
  9057. me then they sould have a rather complete knowledge of Faircom's c-tree
  9058. and r-tree database and report programs. (Oh, and before you ask, noI did
  9059. NOT use d-tree to develop my application!).
  9060. So, if you know r-tree quite well, then I would appreciate you letting me
  9061. know, and I will post the description of my problem here, and you can try
  9062. and solve it for me. I just wish that r-tree had a manual which was
  9063. HALFWAY as complete as the d-tree manual. If it helps, I am using c-tree
  9064. version 4.3 release D and r-tree version 1.1 release F.
  9065. I thank you all in anticipation,
  9066. Kean Johnston
  9067. UUCP: wiz@tabbs.UUCP
  9068. UUCP: ..!ddsw1!olsa99!tabbs!wiz
  9069. ---------------
  9070. Following thread
  9071.  
  9072. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 32QR2331 Date: 02/21/90
  9073. From: JOHN HEIM                                             Time: 10:38 pm
  9074.   To: KEAN JOHNSTON (Rcvd)                                  (Read 97 times)
  9075. Subj: R: R-TREE HELP PLEASE?
  9076.  
  9077. If nobody on Exec can help you might check Compuserve and BIX to see if
  9078. Faircomm has a tech support conference there.  I have subscriptions on
  9079. each so I could check for you if you'd like.
  9080.  
  9081. John
  9082. ---------------
  9083. ** Current thread: R-TREE HELP PLEASE?
  9084.  
  9085. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 32RB1950 Date: 02/22/90
  9086. From: KEAN JOHNSTON                                         Time: 07:32 am
  9087.   To: JOHN HEIM (Rcvd)                                      (Read 102 times)
  9088. Subj: R: R-TREE HELP PLEASE?
  9089.  
  9090. John - I woish I could ask Faircom for help directly, but unfortunately
  9091. they wont deal with us because we are from South Africa. We have to go
  9092. through back doors just to get the product, which is sad, sincewe have
  9093. been using Faircom products for years. The same thing happened with
  9094. Solution Systems, who will no longer supply us with BRIEF updates - we
  9095. now have to purchase a brand new copy of BRIEF every time it is upgraded.
  9096. Silly, I know, but true.
  9097. I just hope that if anyone on this BBS can help me, that they will just
  9098. forget about my country of origin and help a fellow C programmer out.
  9099. Yours sincerely,
  9100. Kean Johnston
  9101. UUCP: wiz@tabbs.UUCP
  9102. UUCP: ..!ddsw1!olsa99!tabbs!wiz
  9103. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  9104.  
  9105. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 32UH3033 Date: 02/25/90
  9106. From: RICHARD POELING                                       Time: 01:50 pm
  9107.   To: ALL                                                   (Read 82 times)
  9108. Subj: C COMPILER DIFFERENCES
  9109.  
  9110. I'm sure this question has probably been asked before, but I need to ask
  9111. it anyway.  I am planning on purchasing a new C Compiler to replace the
  9112. Power C that I use.  I don't know if it doesn't like my computer or what,
  9113. but there are too many times when I can't get the programs I compile hang
  9114. up.  In addition, programs that they have already compiled (they have a
  9115. set of unix like programs for dos) often hang up as well.  These usually
  9116. include those that perform direct access to the disks.
  9117.  
  9118. At any rate, it's time for a change.  I have been thinking about buying
  9119. Microsoft C compiler.  However I have heard people talking about Quick C
  9120. and Turbo C as well.  Since Microsoft C is more expensive than the others,
  9121. one might assume that it can do everything the other two can do and more.
  9122. Is this true?  Or can the other two do things that Microsoft C can't.
  9123. Would I be better off to buy all three?
  9124.  
  9125. If somone can give me some info on this, I sure would appreciate it.
  9126.  
  9127. Thanks, Rick.
  9128. ---------------
  9129. Following thread
  9130.  
  9131. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 32UL3133 Date: 02/25/90
  9132. From: NESHAM SOFTWARE                                       Time: 05:52 pm
  9133.   To: RICHARD POELING (Rcvd)                                (Read 91 times)
  9134. Subj: R: C COMPILER DIFFERENCES
  9135.  
  9136.    Gee, should I touch this?  Aw, why not. I program at work using the
  9137. Microsoft C compiler. At my home office we use the Turbo C compiler.
  9138. The Quick C compiler comes with the MSC5.1 compiler. Turbo C is
  9139. definately the more bang for the buck. In fact, Turbo C is as good in
  9140. most areas as MSC. And better in others.
  9141. Turbo C gives the ability to compile and edit within one integrated
  9142. environment a large project. I think that is the key word - large.
  9143. MSC can compile and edit within the same environment via the M editor
  9144. but memory is usually inadequate to compile many modules and link them
  9145. at the touch of a keystroke. TC has no problems compiling a large project
  9146. and linking. TC has very good speed compared to MSC - TC will always win
  9147. and the optimization is very good. TC's debugger is superior and can
  9148. take an MSC exe and convert it to TC's debugger format. QUICK C is weak
  9149. with large projects and will run out of memory.
  9150.   However, the future will bring MSC 6.0 which is supposed to have a fully
  9151. integrated environment and hypertext capabilities. I am looking forward to
  9152. using this.  Also, Turbo C will incorporate C++ into its compiler and I am
  9153. looking forward to that as well. You can't go wrong with either compiler.
  9154.   Unless you intend to get into OS2, the speed of TC is worth whatever
  9155. psychological discomfort it may bring. Put another way, if TC and MSC were
  9156. the same price I would still but TC.
  9157.  
  9158.    Tim
  9159. ---------------
  9160. ** Current thread: C COMPILER DIFFERENCES
  9161.  
  9162. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 32UM0318 Date: 02/25/90
  9163. From: JIM MONROE                                            Time: 06:05 pm
  9164.   To: NESHAM SOFTWARE (Rcvd)                                (Read 98 times)
  9165. Subj: R: C COMPILER DIFFERENCES
  9166.  
  9167. I have been using the Power C for about 2 years and I am very happy happy
  9168. with the work. There are a number of syntax differences between tc and
  9169. powerc but I have not had many problems
  9170. ---------------
  9171. ** Current thread: C COMPILER DIFFERENCES
  9172.  
  9173. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 32VD3559 Date: 02/26/90
  9174. From: KEAN JOHNSTON                                         Time: 09:59 am
  9175.   To: RICHARD POELING (Rcvd)                                (Read 84 times)
  9176. Subj: R: C COMPILER DIFFERENCES
  9177.  
  9178. Rick.
  9179. I have researched at some lemgth the virtues of the various C compilers on
  9180. the market. I hope that the following is of some value to you:
  9181. TURBO C 2.0: A fine compiler, with good text window support, and very
  9182. quick compile times. It prm<ªjæ÷oduces clean, fast code. However, I have
  9183. had problems with TC when using the large memory model which I don't
  9184. experience with MSC 5.1. Without being biased, Borland products invariably
  9185. seem to fail when you push them to the limit. √·╓√▀
  9186. Microsoft Optomising C compiler V5.1: My personal favourite. It is not as
  9187. fast in terms of compile times as TC2.0, but the optomiser seems to be
  9188. more stable, and the code it produces is VERY fast. It also seems to
  9189. produce smaller executables than TC2. Also, there seem to be more
  9190. libraries availble for MSC.
  9191. Quick C 2.0: This is just a scaled down version of MSC 5.1. It has an
  9192. integrated development environment like TC does, and an excelent HyperText
  9193. help system which knocks TC's into a cocked hat.
  9194. JPI TopSpeed C: I have never used this one personally, but I know several
  9195. people who have, so I can tell you what they think of it. It is compatible
  9196. with both MSC and TC source, as it has a superset of both libraries. It is
  9197. reported to be as fast in compile time as TC2.0, but - it has a smart
  9198. linker.This can drastically reduce the size of your executables. It also
  9199. has a good IDE and help system, a┤╧╣l■M\Σ■╗&\Ωd is reported to be more
  9200. ANSI compatible than both MSC and TC. Those who have used it swear by it,
  9201. and wouldn't use anything else. Also, its debugger is supposed to be quite
  9202. revolutionary.
  9203. It seems as if JPI is the one to go for (I'm waiting for my copy to
  9204. arrive). I will give you a more detailed report on its virtues as soon as
  9205. I have had hands-on experience.
  9206. Regards, and I hope this helps,
  9207. Kean Johnston
  9208. UUCP: wiz@tabbs.UUCP
  9209. UUCP: ..!ddsw1!olsa99!tabbs!wiz
  9210. ---------------
  9211. ** Current thread: C COMPILER DIFFERENCES
  9212.  
  9213. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 32VK2461 Date: 02/26/90
  9214. From: NESHAM SOFTWARE                                       Time: 04:41 pm
  9215.   To: JIM MONROE (Rcvd)                                     (Read 82 times)
  9216. Subj: R: C COMPILER DIFFERENCES
  9217.  
  9218.   That used to called MIX C I believe. I started with that compiler. By
  9219. far it has the most bang for the buck!
  9220.  
  9221.   Tim
  9222. ---------------
  9223. ** Current thread: C COMPILER DIFFERENCES
  9224.  
  9225. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 32VK2791 Date: 02/26/90
  9226. From: GLEN THOMPSON                                         Time: 04:46 pm
  9227.   To: RICHARD POELING (Rcvd)                                (Read 82 times)
  9228. Subj: R: C COMPILER DIFFERENCES
  9229.  
  9230. Rick,
  9231.  
  9232. I've used the older Microsoft compilers and prefer Turbo C.  The original
  9233. Quick C was almost worthless.  The newer versions are better.  You're
  9234. going to get a lot of opinions on this since picking a compiler is very
  9235. subjective.  Borland offers the best price/performance in Turbo C while
  9236. the full blown MS C has some advantages like OS/2 support.
  9237.  
  9238. Borland is working on a deal with Watcom to make the two compilers
  9239. compatible so you can use Turbo C for prototyping and Watcom C for the
  9240. final versions.  Watcom C has some of the best optimization routines in
  9241. the business.
  9242.  
  9243. glen
  9244. ---------------
  9245. ** Current thread: C COMPILER DIFFERENCES
  9246.  
  9247. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 333F2653 Date: 03/03/90
  9248. From: GRANT ELLSWORTH (Leader)                              Time: 11:44 am
  9249.   To: RICHARD POELING (Rcvd)                                (Read 90 times)
  9250. Subj: R: C COMPILER DIFFERENCES
  9251.  
  9252. Rick, I think our colleagues have given you some useful info.  But, I'd
  9253. like to supplement it with a few comments of my own.  With specific com-
  9254. parisions of TC, MSC, and others, I lean strongly away from using MSC
  9255. unless there is a COMPELLING reason to do so --- such as: need to do
  9256. Oh-S***/2 NOW, or some support lib for special purpose (hardware/soft-
  9257. ware function) is available only in MSC and vendor has unwisely said
  9258. MSC ONLY yesterday, today, and forever!.  My primary reason is that
  9259. I have stumbled into too many "glitches" when using MSC.  These have
  9260. varied from undocumented/or poorly and obscurely documented design
  9261. deficiencies, improperly generated code --- especially when letting
  9262. some optimizations take effect, thru documented to do it one way and
  9263. actually does it another (while puking all over you in the process).
  9264. Now, I am told that MSC 5.1 adresses some of the paddies I have stepped
  9265. into, but my expereience has been such that I do not trust this product.
  9266. For all the claims and raves about this thing as being the "industry
  9267. standard", it has been, at best, the lowest common denominator of
  9268. true garbage and useable programming tools.   That's my considered
  9269. opinion and experience.  TC, on the other hand, has given me far
  9270. fewer problems --- particularly the current release (2.01).
  9271.  
  9272. On the matter of optimization and effective production of time-efficient
  9273. code, MSC has done a better job than TC.  But, the garbage that you
  9274. risk stepping into in achieving your optimized results can cost too
  9275. much time to wade out of.  Also, if optimized code is of prime importance,
  9276. then WatCom C seems to be the better choice.
  9277.  
  9278. For self-teaching and learning to use C, I have found both TC and
  9279. MIX Power C good devices.  BUt, you need a general purpose C book
  9280. on hand to supplement the vendor supplied documentation.  This is true
  9281. for any C compiler.
  9282.  
  9283. Lastly, programmers don't write perfect code.  And the clerical errors
  9284. are sometimes more destructive than the logic or design errors and are
  9285. often harder to find.  Hence you need a good symbolic debugger.  For my
  9286. money, the Turbo Debugger is in a class way out in front by itself, leav--
  9287. ing MS Codeview and Watcom's WVideo somewhere way back in the track.  But,
  9288. I will say that CodeView and WVideo are useable.
  9289.  
  9290. Hope these comments add to your considerations.  Enjoy your C programming
  9291. experience whatever compiler you choose.  Regards, Grant
  9292. ---------------
  9293. ** Current thread: C COMPILER DIFFERENCES
  9294.  
  9295. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 333H3481 Date: 03/03/90
  9296. From: JOHN HEIM                                             Time: 01:58 pm
  9297.   To: RICHARD POELING (Rcvd)                                (Read 84 times)
  9298. Subj: R: C COMPILER DIFFERENCES
  9299.  
  9300. Rick,
  9301.  
  9302. With all the discussion I'm surprised no one mentioned the fact that Quick
  9303. C's editor is infinately better than Turbo C's.  I have yet to meet anyone
  9304. who is comfortable with both and isn't fustrated by Turbo's editor.  I
  9305. think QuickC's editor may be the best available anywhere (though I hear
  9306. Brief is pretty good).  It's better than emacs, VI, and Turbo anyway.
  9307.  
  9308. However, Turbo is definately the superior compiler and when I had to
  9309. choose which to buy for my own use at home, I chose Turbo even though I
  9310. think the editor sucks.
  9311.  
  9312. QuickC's (and MSC's) speed, exe size, and libraries are all more than
  9313. adequate for most jobs.  If you're going to be doing routine programming
  9314. but lot's of it, the quality of QuickC's editor might make it the right
  9315. product for you.
  9316.  
  9317. John
  9318. ---------------
  9319. ** Current thread: C COMPILER DIFFERENCES
  9320.  
  9321. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 333J1152 Date: 03/03/90
  9322. From: ROBERT BALSOVER                                       Time: 03:19 pm
  9323.   To: JOHN HEIM (Rcvd)                                      (Read 83 times)
  9324. Subj: R: C COMPILER DIFFERENCES
  9325.  
  9326. John,
  9327. I am comfortable with both and like Borlands editor better.  In fact I had
  9328. QC and dumped it for TC.
  9329. Bob
  9330. ---------------
  9331. ** Current thread: C COMPILER DIFFERENCES
  9332.  
  9333. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 333M1087 Date: 03/03/90
  9334. From: JIM MONROE                                            Time: 06:18 pm
  9335.   To: NESHAM SOFTWARE (Rcvd)                                (Read 79 times)
  9336. Subj: R: C COMPILER DIFFERENCES
  9337.  
  9338. I beleive that they (MIX) will be relaeseing the multiple memory model
  9339. version shortly. This seems to be the only problem that I have had sofar
  9340. in my beginning travel into C programing.
  9341. ---------------
  9342. ** Current thread: C COMPILER DIFFERENCES
  9343.  
  9344. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 334R0796 Date: 03/04/90
  9345. From: JOHN HEIM                                             Time: 10:13 pm
  9346.   To: ROBERT BALSOVER (Rcvd)                                (Read 84 times)
  9347. Subj: R: C COMPILER DIFFERENCES
  9348.  
  9349. You like typing ^KB and ^KK just to mark a block?  In QuickC you just hold
  9350. the shift key down and use the arrows.  Also to copy a block from one file
  9351. to another in Turbo you have to write it to disk.  My TC directory is
  9352. full of temporary files because of this.  And, if there's a SEARCH hotkey
  9353. in Turbo I have yet to find it.  In QuickC is't ^\.
  9354.  
  9355. People are always complaining about the editor in Borlands conference on
  9356. Compuserve.  This has lead to a great deal of speculation that they're
  9357. going to change it for their next release.
  9358.  
  9359. Are you really comfortable with QuickC's editor?  What don't you like
  9360. about it?
  9361.  
  9362. John
  9363. ---------------
  9364. ** Current thread: C COMPILER DIFFERENCES
  9365.  
  9366. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 335M0904 Date: 03/05/90
  9367. From: NESHAM SOFTWARE                                       Time: 06:15 pm
  9368.   To: JOHN HEIM (Rcvd)                                      (Read 79 times)
  9369. Subj: R: C COMPILER DIFFERENCES
  9370.  
  9371.   I downloaded the recent version of Qedit from this board. A superior
  9372. editor to Turbo C. It now does column blocking and swaps to expanded
  9373. memory or disk. I loaded Turbo C via Qedit and compiled! Of course
  9374. I have a 386.
  9375.  
  9376.     Tim
  9377. ---------------
  9378. ** Current thread: C COMPILER DIFFERENCES
  9379.  
  9380. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 335N1741 Date: 03/05/90
  9381. From: ROBERT BALSOVER                                       Time: 07:29 pm
  9382.   To: JOHN HEIM (Rcvd)                                      (Read 80 times)
  9383. Subj: R: C COMPILER DIFFERENCES
  9384.  
  9385. John,
  9386. Part of the reason I like TC's IDE is it mimics something I'm use to,
  9387. Wordstar.  I'm also not a mouser.  As far as those temporary files used to
  9388. transfer block's, it's something they should have thought of, but also
  9389. there are times I wish to have it in a temporary file.
  9390. .
  9391. As far as people in the BPROGB forem complaining about the editor, funny I
  9392. never once have seen that and I'm on daily.
  9393. .
  9394. If all of those little files in your TC directory bother you, try using
  9395. the same name each time you do it, then you'll only have one temporary
  9396. file.  But, in the end it's just a matter of personal taste right?
  9397. Bob
  9398. ---------------
  9399. ** Current thread: C COMPILER DIFFERENCES
  9400.  
  9401. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 335Q1417 Date: 03/05/90
  9402. From: JOHN HEIM                                             Time: 09:23 pm
  9403.   To: NESHAM SOFTWARE (Rcvd)                                (Read 81 times)
  9404. Subj: R: C COMPILER DIFFERENCES
  9405.  
  9406. Do you loose the integrated environment when you do that?  You cant still
  9407. set break points and watch variables using Qedit can you?
  9408.  
  9409. John
  9410. ---------------
  9411. ** Current thread: C COMPILER DIFFERENCES
  9412.  
  9413. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 335Q2561 Date: 03/05/90
  9414. From: JOHN HEIM                                             Time: 09:42 pm
  9415.   To: ROBERT BALSOVER (Rcvd)                                (Read 80 times)
  9416. Subj: R: C COMPILER DIFFERENCES
  9417.  
  9418. Yes, it's a matter of personal taste.  But my point was that all other
  9419. things being equil, an impartial observer would like QuickC's editor much
  9420. better.  I anticipated people saying they used both but liked Turbo's
  9421. editor better but I really think it's only because they're more familiar
  9422. with Turbo's editor.
  9423.  
  9424. Lets face it, it just plain takes a lot more keystrokes to do the same
  9425. thing in Turbo C's editor than in QuickC and it's a lot less intuitive.
  9426.  
  9427. John
  9428.  
  9429. PS.  I was reading a bunch of messages about how Borland could improve TC
  9430. about 4-5 months ago.  I think it was in Borlands conference on Compuserve
  9431. but I wouldn't swear to it.
  9432. ---------------
  9433. ** Current thread: C COMPILER DIFFERENCES
  9434.  
  9435. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33AL3496 Date: 03/06/90
  9436. From: GRANT ELLSWORTH (Leader)                              Time: 05:58 pm
  9437.   To: JOHN HEIM (Rcvd)                                      (Read 87 times)
  9438. Subj: R: C COMPILER DIFFERENCES
  9439.  
  9440. John, Re: TC's built-in editor ... I agree, the editor is a bit archaic,
  9441. but, at the time it was first put together, there were a lot of us who
  9442. were broken in on the WordStar editor from CP/M.  All told, I find it
  9443. quite usable except where I wish like heck it had multiple window/file
  9444. capability and that I could cut and paste between windows without
  9445. writing a marked block to an intermediate file.  The search hot key
  9446. (to the extent it's really a hot key) is ^L which repeats the last
  9447. find or find/replace.  I haven't tried the new QC editor, so I can't
  9448. comment on it, but the last release I tried left much to be desired
  9449. and much to wish for.
  9450.  
  9451. Maybe the best thing that could happen would be for Borland to come
  9452. up with a totally different editor with a snazzier user interface and
  9453. a radical departure from the WordStar keystrokes.  But as a Wordstar
  9454. (current) user (of 4.0) and a vet Wordstar user at that (going back to
  9455. the CP/M version), I'd find those very old ingrained habits very hard
  9456. to break.   Grant
  9457. ---------------
  9458. ** Current thread: C COMPILER DIFFERENCES
  9459.  
  9460. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33AQ3052 Date: 03/06/90
  9461. From: ROBERT BALSOVER                                       Time: 09:50 pm
  9462.   To: JOHN HEIM (Rcvd)                                      (Read 90 times)
  9463. Subj: R: C COMPILER DIFFERENCES
  9464.  
  9465. John,
  9466. Isn't hard for you to say what a impartial person would say, when you are
  9467. obviously not impartial.
  9468. Bob
  9469. ---------------
  9470. ** Current thread: C COMPILER DIFFERENCES
  9471.  
  9472. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33BM0759 Date: 03/07/90
  9473. From: NESHAM SOFTWARE                                       Time: 06:12 pm
  9474.   To: JOHN HEIM (Rcvd)                                      (Read 80 times)
  9475. Subj: R: C COMPILER DIFFERENCES
  9476.  
  9477.    I don't use the debugger in the environment. However I don't see why
  9478. not. To swap out to memory, Qedit loads a 7k shell plus command.com or
  9479. a total of about 10k(?). So you have total_memory - 10k for TC! Of course
  9480. the more .obj's that are compiled with symbolic info the worse.
  9481.  
  9482.    Tim
  9483. ---------------
  9484. ** Current thread: C COMPILER DIFFERENCES
  9485.  
  9486. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33BM0965 Date: 03/07/90
  9487. From: NESHAM SOFTWARE                                       Time: 06:16 pm
  9488.   To: JOHN HEIM (Rcvd)                                      (Read 82 times)
  9489. Subj: R: C COMPILER DIFFERENCES
  9490.  
  9491.    I have used both TC and QC editors and agree with you about the key
  9492. definitions. But they are fully configurable. Why on earth would
  9493. programmers CARE what the default key definitions are when they can set
  9494. them themselves? Can TC mark columns? Can QC? M.exe can.
  9495.  
  9496.    Tim
  9497. ---------------
  9498. ** Current thread: C COMPILER DIFFERENCES
  9499.  
  9500. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33BN1541 Date: 03/07/90
  9501. From: JOHN HEIM                                             Time: 07:25 pm
  9502.   To: GRANT ELLSWORTH (Rcvd)                                (Read 80 times)
  9503. Subj: R: C COMPILER DIFFERENCES
  9504.  
  9505. I don't know.  I've heard from rumors from 2 different sources that
  9506. Borlands gonna change the editor.  I'm sure they'll let the old commands
  9507. work too.  It'd be too bad for PR (not to mention the sanity of the
  9508. installed user base) to do otherwise.
  9509.  
  9510. John
  9511. ---------------
  9512. ** Current thread: C COMPILER DIFFERENCES
  9513.  
  9514. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33BN2027 Date: 03/07/90
  9515. From: JOHN HEIM                                             Time: 07:33 pm
  9516.   To: ROBERT BALSOVER (Rcvd)                                (Read 81 times)
  9517. Subj: R: C COMPILER DIFFERENCES
  9518.  
  9519. I am impartial.  After all I own Turbo C.  Don't you think I'd stick up
  9520. for my own choice of compiler?  I happened to have learned them both at
  9521. approximately the same time.  Anyway, the editor alone is no reason to
  9522. choose a compiler.  I choose Turbo C because it's better in almost every
  9523. other way.
  9524. ---------------
  9525. ** Current thread: C COMPILER DIFFERENCES
  9526.  
  9527. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33BN2605 Date: 03/07/90
  9528. From: JOHN HEIM                                             Time: 07:43 pm
  9529.   To: NESHAM SOFTWARE (Rcvd)                                (Read 79 times)
  9530. Subj: R: C COMPILER DIFFERENCES
  9531.  
  9532. RE: Can TC mark columns? Can QC?
  9533.  
  9534. I don't know.  What do you mean 'mark columns'.  Like this ...
  9535.  
  9536. main (argc, ARGV)
  9537. int       arGC;
  9538. char      **ARGV;
  9539. {
  9540.      printf("HELLo world\n);
  9541. }
  9542.  
  9543. Where colums 13-16 are marked (indicated with capital letters).  That
  9544. might be good for fixing messed up indentation.  Both TC and QC allow you
  9545. to mark part of a line.  Like so ...
  9546.  
  9547. main (argc, argv)
  9548. int     argc;
  9549. char     **arGV;
  9550. {
  9551.      PRINTF("HELLo world\n);
  9552. }
  9553.  
  9554. Where the last three chars of the 3rd line through the 2nd L in hello are
  9555. marked.
  9556. ---------------
  9557. ** Current thread: C COMPILER DIFFERENCES
  9558.  
  9559. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33DR1836 Date: 03/09/90
  9560. From: ROBERT BALSOVER                                       Time: 10:30 pm
  9561.   To: JOHN HEIM (Rcvd)                                      (Read 78 times)
  9562. Subj: R: C COMPILER DIFFERENCES
  9563.  
  9564. John,
  9565. You're right, the editor is far from the most important reason to choose a
  9566. compiler.
  9567. Bob
  9568. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  9569.  
  9570. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 32VP1221 Date: 02/26/90
  9571. From: RICHARD PLAMAN                                        Time: 08:20 pm
  9572.   To: ALL                                                   (Read 82 times)
  9573. Subj: HISTOGRAM
  9574.  
  9575. being a novice presently enrolled at MATC, one of our assignments is to
  9576. program a loop array then produce a histogram (horizontal) to indicate the
  9577. length of each of the values.  I am having trouble in multiplying the
  9578. character times the int.  In other words, if n is my char and my first
  9579. index is 5 I would want to see 'nnnnn'.  I cannot even describe what I am
  9580. getting.  All kinds of graphics characters.  Can anyone help me?
  9581. ---------------
  9582. Following thread
  9583.  
  9584. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 32VS0127 Date: 02/26/90
  9585. From: RICHARD POELING                                       Time: 11:02 pm
  9586.   To: RICHARD PLAMAN (Rcvd)                                 (Read 87 times)
  9587. Subj: R: HISTOGRAM
  9588.  
  9589. Unless I'm not reading far enough into your message, it sounds like a
  9590. rather simple problem.
  9591.  
  9592. int value;
  9593. char histo;
  9594.  
  9595. value = 5;
  9596. histo = 'n';
  9597.  
  9598. while(value--)
  9599.      putchar(histo);
  9600. ---------------
  9601. ** Current thread: HISTOGRAM
  9602.  
  9603. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 32WN0197 Date: 02/27/90
  9604. From: RICHARD PLAMAN                                        Time: 07:03 pm
  9605.   To: RICHARD POELING (Rcvd)                                (Read 78 times)
  9606. Subj: R: HISTOGRAM
  9607.  
  9608. Richard,
  9609.      thanks, I will try it.  I was attempting to multiply n times the
  9610. index with some very wild results.  This is a real learning experience,
  9611. and I thank you again.
  9612. ---------------
  9613. ** Current thread: HISTOGRAM
  9614.  
  9615. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 32WQ1838 Date: 02/27/90
  9616. From: MICHAEL MCCLUNE                                       Time: 09:30 pm
  9617.   To: RICHARD PLAMAN (Rcvd)                                 (Read 81 times)
  9618. Subj: R: HISTOGRAM
  9619.  
  9620. Richard,
  9621. I read your poser a little differently, here would be my solution.
  9622. #include <stdio.h>          /* need for printf() */
  9623. void main(void)
  9624. {
  9625.   int i=0;                  /* decalre and initilize */
  9626.   char array[6]={""};       /* decalre and initilize array */
  9627.                             /* 5 for the char and 1 for NULL terminator */
  9628.   while(i<=4)
  9629.   {
  9630.     array[i]='n';           /* fill array */
  9631.     i++;                    /* increment variable */
  9632.   }
  9633.   printf("%s",array);       /* print the string */
  9634. }                           /* end of main() */
  9635.  
  9636. the reason for not incrementing the var i in the while loop is that the
  9637. var would be incremented once before the loop actually executed.
  9638. Give this a try once maybe its what your looking for.
  9639.  
  9640. Mike
  9641. ---------------
  9642. ** Current thread: HISTOGRAM
  9643.  
  9644. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 331P1313 Date: 03/01/90
  9645. From: RICHARD PLAMAN                                        Time: 08:21 pm
  9646.   To: MICHAEL MCCLUNE (Rcvd)                                (Read 86 times)
  9647. Subj: R: HISTOGRAM
  9648.  
  9649. Michael,
  9650.      Thank you for responding.  These arrays are still much foreign to me.
  9651. I got it to work OK, but intended to load the table, and then draw the
  9652. histogram.  As it is, the histogram echo's after each number is input.  I
  9653. will give your code a try.  Thanks again for taking the time to respond.
  9654. ---------------
  9655. ** Current thread: HISTOGRAM
  9656.  
  9657. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 335N1720 Date: 03/05/90
  9658. From: RICHARD PLAMAN                                        Time: 07:28 pm
  9659.   To: JIM MONROE (Rcvd)                                     (Read 77 times)
  9660. Subj: R: HISTOGRAM
  9661.  
  9662. Jim,
  9663.      thanks for the advice.  It is becomming clearer.  I am learning that
  9664. there is definitely more than one way to skin a cat.  Again, thank you.
  9665. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  9666.  
  9667. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 32X31613 Date: 02/28/90
  9668. From: STEVE LIN                                             Time: 03:26 am
  9669.   To: ALL                                                   (Read 85 times)
  9670. Subj: COMM I/O ROUTINES
  9671.  
  9672. I'm searching for some routines
  9673. which will show me exactly how to conduct comm port i/o with Turbo C on my
  9674. machine. I want to be able to redirect text to both the local console and
  9675. the remote as well as monitor carrier and accept input from both local and
  9676. remote.
  9677.  
  9678. Does anyone have a solution?
  9679.  
  9680. Thanks in advance!
  9681. ---------------
  9682. Following thread
  9683.  
  9684. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33SI1096 Date: 03/23/90
  9685. From: JEFF NOWLAND                                          Time: 02:18 pm
  9686.   To: STEVE LIN (Rcvd)                                      (Read 81 times)
  9687. Subj: R: COMM I/O ROUTINES
  9688.  
  9689. Steve,
  9690. There is a book out called C programmers guide to serial communications. I
  9691. forget the author's name off hand , but it does a good job of explaining
  9692. the whole thing and gives beaucoup code.
  9693. JDNowland!
  9694. ---------------
  9695. ** Current thread: COMM I/O ROUTINES
  9696.  
  9697. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33SJ0088 Date: 03/23/90
  9698. From: ROBERT BALSOVER                                       Time: 03:01 pm
  9699.   To: JEFF NOWLAND (Rcvd)                                   (Read 77 times)
  9700. Subj: R: COMM I/O ROUTINES
  9701.  
  9702. Jeff & Steve,
  9703. The authors name is Joe Campbell, the publisher is Howard Sams & Co.
  9704. Bob
  9705. ---------------
  9706. ** Current thread: COMM I/O ROUTINES
  9707.  
  9708. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33SJ0175 Date: 03/23/90
  9709. From: ROBERT BALSOVER                                       Time: 03:02 pm
  9710.   To: JEFF NOWLAND (Rcvd)                                   (Read 80 times)
  9711. Subj: R: COMM I/O ROUTINES
  9712.  
  9713. A word of warning, if you use the material with TC, you have to stay in
  9714. the small model.  Various bugs pop up in the large model.
  9715. Bob
  9716. ---------------
  9717. ** Current thread: COMM I/O ROUTINES
  9718.  
  9719. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33^G0266 Date: 03/31/90
  9720. From: JEFF NOWLAND                                          Time: 12:04 pm
  9721.   To: ROBERT BALSOVER (Rcvd)                                (Read 79 times)
  9722. Subj: R: COMM I/O ROUTINES
  9723.  
  9724. I've been hearing some comments about TC in the large memory model having
  9725. bugs!  Are you referring to the Campbell material specifically or TC's
  9726. large memory model.  I've been using TC since v1.00 and have thus far been
  9727. able to identify all known bugs in my programs and explain them in terms
  9728. of my code.  If TC is the problem, can anyone tell me what that problem
  9729. is.
  9730. JDNowland.
  9731. ---------------
  9732. ** Current thread: COMM I/O ROUTINES
  9733.  
  9734. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33^G0983 Date: 03/31/90
  9735. From: JEFF NOWLAND                                          Time: 12:16 pm
  9736.   To: JEFF NOWLAND (Rcvd)                                   (Read 76 times)
  9737. Subj: R: COMM I/O ROUTINES
  9738.  
  9739. Looks like I should have read the rest of the messages here before leaving
  9740. last one.  Had me in a panick for a minute!
  9741. JDNowland!
  9742. ---------------
  9743. ** Current thread: COMM I/O ROUTINES
  9744.  
  9745. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33^M0394 Date: 03/31/90
  9746. From: ROBERT BALSOVER                                       Time: 06:06 pm
  9747.   To: JEFF NOWLAND (Rcvd)                                   (Read 75 times)
  9748. Subj: R: COMM I/O ROUTINES
  9749.  
  9750. Jeff,
  9751. I was refering to Campbells material.  TC isn't any problem at all, but
  9752. you knew that already.<grin>
  9753. Bob
  9754. ---------------
  9755. ** Current thread: COMM I/O ROUTINES
  9756.  
  9757. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 354Q1517 Date: 05/04/90
  9758. From: STEVE LIN                                             Time: 09:25 pm
  9759.   To: JEFF NOWLAND (Rcvd)                                   (Read 76 times)
  9760. Subj: R: COMM I/O ROUTINES
  9761.  
  9762. Yes, I know about that book. It's based on MSC, y'know. I'm much more
  9763. favorable with TC... the last MSC version I have is 4.00... that's good
  9764. enough for me. I did manage to get routines to punch into FOSSIL drivers.
  9765. ---------------
  9766. ** Current thread: COMM I/O ROUTINES
  9767.  
  9768. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35TR1063 Date: 05/24/90
  9769. From: STEVE LIN                                             Time: 10:17 pm
  9770.   To: JEFF NOWLAND (Rcvd)                                   (Read 75 times)
  9771. Subj: R: COMM I/O ROUTINES
  9772.  
  9773. Okay, thanks, Jeff.
  9774. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  9775.  
  9776. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 32XR2743 Date: 02/28/90
  9777. From: CLIVE JENKINS                                         Time: 10:45 pm
  9778.   To: ALL                                                   (Read 87 times)
  9779. Subj: HELP WITH CALLOC.
  9780.  
  9781. I'm looking for some help from a knowledgeable C programmer.
  9782. (#define knowledgeable all readers since I'm new to programming in C.)
  9783.     I've been writing a program where I need to set up a 2-dimensional
  9784. array
  9785. at run time, and had hoped simply to use calloc and be able to access with
  9786. *(*(array+i)+j) notation.  When I try
  9787.         array = (int *) calloc(Y, X*2);   /* for array[Y][X] */
  9788. I get memory allocation where array+n gets the n-th integer, but double
  9789. indirection gets an "invalid indirection" error from the compiler. I've
  9790. been
  9791. able to do what I want by allocating memory for a second array for
  9792. pointers:
  9793.         ptr = (int *) calloc(Y, 2);
  9794.         for(i=0; i<Y; i++)
  9795.             *(ptr + i) = array + i*X;
  9796. and can then access array[i][j].  I still can't use the expression:
  9797.         *(*(ptr+i)+j*2)  /* the 2 needs to be there to get the next
  9798. integer
  9799.                             rather than the next byte */
  9800. but need to do the following variable assignment first:
  9801.         address = *(ptr+i) + j*2;
  9802.         ij_array_element = *address;
  9803.     Even though what I've done works, it's messy.  Any suggestions for a
  9804. more
  9805. elegant method?
  9806.  
  9807.  
  9808.  
  9809.  
  9810. ---------------
  9811. Following thread
  9812.  
  9813. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33SI1411 Date: 03/23/90
  9814. From: JEFF NOWLAND                                          Time: 02:23 pm
  9815.   To: CLIVE JENKINS                                         (Read 77 times)
  9816. Subj: R: HELP WITH CALLOC.
  9817.  
  9818. Clive,
  9819. Since you are creating dynamically a two dimensional array, ptr must be
  9820. declared as int **. Then the following should work:
  9821. int **ptr;
  9822.   ptr = (int **)calloc( Y, sizeof( int * ) );
  9823.   for( i = 0; i < Y; i++ )
  9824.     ptr[i] = (int *)calloc( X, sizeof( int ) );
  9825. you should then be able to access the array as either
  9826.   *( *(ptr+i) + j ) or ptr[i][[j]
  9827. happy hunting!
  9828. JDNowland!
  9829. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  9830.  
  9831. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 331M2743 Date: 03/01/90
  9832. From: JOE VINCENT                                           Time: 06:45 pm
  9833.   To: ALL                                                   (Read 83 times)
  9834. Subj: PERSONAL HI, GENE!
  9835.  
  9836. Message CC'd to:
  9837.      GRANT ELLSWORTH
  9838.      GENE ALM
  9839.      ALL
  9840.  
  9841. I received a brochure in the mail this week from UMW advertising a seminar
  9842. on "'C' Programming with Style and Discipline."  I opened it to see who
  9843. was the instructor and it turned out to be none other than the erudite Dr.
  9844. Eugene J. Alm!  "Hey!", I said to my wife, "I know this guy!"
  9845.  
  9846. Oh, how the meek in spirit have been elevated!  And nobody deserves the
  9847. recognition more than Gene, who has helped many of us unselfishly here on
  9848. Exec with our mundane C problems.  Go get 'em, Gene!
  9849.  
  9850. (Still haven't figured out why they mailed such a high-falutin'
  9851. solicitation to Kentucky!)
  9852.  
  9853.      -=≡{JOE}≡=- (tm)
  9854. ---------------
  9855. Following thread
  9856.  
  9857. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 332D3391 Date: 03/02/90
  9858. From: GREG FRANCIS                                          Time: 09:56 am
  9859.   To: ALL                                                   (Read 83 times)
  9860. Subj: C PROGRAMMERS IN MADISON
  9861.  
  9862.                                 HELP WANTED
  9863.  
  9864.        We   are  seeking  systems  and  applications  programmers   and
  9865.        engineers  with   a   minimum of 2  years  experience  in  Intel
  9866.        Assembler  and  C language  programming  and a bachelor's degree
  9867.        in Computer Science, Engineering or Physics.   The openings  are
  9868.        immediate  and the company is a well established   Madison  area
  9869.        manufacturer   of  leading edge scientific   products.    Please
  9870.        send all replies to:
  9871.  
  9872.                                 GREG FRANCIS
  9873.  
  9874.        Any referrals would be appreciated.
  9875. ---------------
  9876.  
  9877. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 333I0807 Date: 03/03/90
  9878. From: JOHN HEIM                                             Time: 02:13 pm
  9879.   To: ALL                                                   (Read 78 times)
  9880. Subj: MARK WILLIAMS C
  9881.  
  9882. All this talk about compilers has got me thinking about the first compiler
  9883. I ever bought.  About 4 years ago Mark Williams Co came out with a C
  9884. compiler with a source code debugger for $75.  This was several months
  9885. before Microsoft released QuickC (which I believe sold for $150 then).  So
  9886. it was a pretty good deal.  But I haven't heard anything about it since.
  9887. Anybody know what happened?
  9888.  
  9889. John
  9890. ---------------
  9891.  
  9892. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 333K2689 Date: 03/03/90
  9893. From: RICHARD POELING                                       Time: 04:44 pm
  9894.   To: ALL                                                   (Read 85 times)
  9895. Subj: TURBO C VS. TURBO C PRO
  9896.  
  9897. I thank all of you who have expressed their views about the various C
  9898. compilers.  It looks like Turbo C is the route I'll be taking.  However,
  9899. now I have to ask which Turbo C I should get.  As long as Turbo C Pro is
  9900. as easy to use as regular Turbo C and ask long as Turbo C Pro has all of
  9901. the features as regular Turbo C and more, then that's the one I'll go
  9902. with.  Can anyone tell me if this is the case?
  9903.  
  9904. Thanks, Rick.
  9905. ---------------
  9906. Following thread
  9907.  
  9908. ?
  9909.  
  9910. ----------
  9911. N (Next): Select "N" (no quotes) to read the next message.  If you're
  9912. currently following a thread, the next message in that thread will display.
  9913. Otherwise, the message immediately following your current message will
  9914. display.
  9915.  
  9916. ----------
  9917. B (Backward): Select "B" (no quotes) to read the previous message.
  9918.  
  9919. ----------
  9920. D (Delete):  Select "D" (no quotes) to delete the current message.  If the
  9921. message is marked and the person it is to hasn't read it, it will
  9922. automatically be unmarked.  After deleting messages, the system automatically
  9923. goes to the next message.  If you're reading a thread, the next message will
  9924. be the next message in the thread.  If you didn't write the current message
  9925. and the message isn't to you, the system will not allow you to delete it.
  9926.  
  9927. ----------
  9928. L (List): Select "L" to list the current message again.
  9929.  
  9930. ----------
  9931. R (Reply): Select "R" to reply to the message you are currently reading.  The
  9932. system will allow you to compose a message that will automatically be sent to
  9933. the person who sent the message you were reading.
  9934.  
  9935. ----------
  9936. P (Private): Select "P" (no quotes) to send a confidential reply to the
  9937. person who left the message you're currently reading.  The resulting reply
  9938. will be hidden from everyone but the person you're replying to and yourself.
  9939.  
  9940. ----------
  9941. M (Mark): Select "M" (no quotes) to keep the current message marked.  You
  9942. can the quickly find it again by reading your marked mail.  If the current
  9943. message isn't to you, the system treats it just like you had pressed "N."
  9944.  
  9945. ----------
  9946. T (Thread):  Select "T" (no quotes) to read messages that share the same
  9947. topic as the current message.  Messages sharing the same subject are
  9948. automatically part of the same thread.  Pressing "T" will start the thread at
  9949. the current message.  You can go backwards in threads by selecting <B>ack
  9950. once you're within the thread.  If there is no thread on the current message,
  9951. the system treats your "T" just like it were an "N."
  9952.  
  9953. ----------
  9954. C (Continuous):  Toggles the state of "pausing after each message".  If you
  9955. told the BBS to pause after each message, hitting the "C" command will make
  9956. it so the BBS no longer pauses after each message.  If you are not pausing
  9957. after each message, hitting "C" will make the BBS begin to pause after each
  9958. message.
  9959.  
  9960. ----------
  9961. A (Abort):  Select "A" (no quotes) to stop reading the current message.  If
  9962. you aren't within a thread, the READ MENU will appear again.  If you are
  9963. reading a thread, the system will abort to the point where you began reading
  9964. the current thread.
  9965.  
  9966. Press any key to continue -> 
  9967. [N]xt (B)ack (L)st (R)ply (P)riv (C)ntuos (T)hrd (A)brt (?=HELP)-> C> Pausing after each message is now ON
  9968. > The current message will now be re-displayed
  9969. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 333P0998 Date: 03/03/90
  9970. From: NESHAM SOFTWARE                                       Time: 08:16 pm
  9971.   To: RICHARD POELING (Rcvd)                                (Read 92 times)
  9972. Subj: R: TURBO C VS. TURBO C PRO
  9973.  
  9974.   Turbo C is the same TC in both alone and pro. With pro you get a
  9975. great debugger and an assembler. Definately worth a few extra bucks.
  9976.  
  9977.   Tim
  9978. ---------------
  9979. ** Current thread: TURBO C VS. TURBO C PRO
  9980. [N]xt (B)ack (L)st (R)ply (P)riv (C)ntuos (T)hrd (A)brt (?=HELP)-> C
  9981. > Pausing after each message is now OFF
  9982.  
  9983. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 334R2420 Date: 03/04/90
  9984. From: JOHN HEIM                                             Time: 10:40 pm
  9985.   To: RICHARD POELING (Rcvd)                                (Read 81 times)
  9986. Subj: R: TURBO C VS. TURBO C PRO
  9987.  
  9988. I agree that Turbo Pro is worth the bucks.  I made the mistake of buying
  9989. just TurboC and eventually ended up buying the Assembr/Debugger separately
  9990. anyway.
  9991.  
  9992. John
  9993. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  9994.  
  9995. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 334F2827 Date: 03/04/90
  9996. From: DEAN LIND                                             Time: 11:47 am
  9997.   To: ALL                                                   (Read 85 times)
  9998. Subj: HUNGARIAN SYNTAX
  9999.  
  10000. I've ocassionally heard reference made to what is called the 'Hungarian'
  10001. syntax or system of naming variables, subroutines etc within a program.
  10002. As I understand it, this is a system of naming conventions that allow you
  10003. to immediately tell exactly what type of variable you're dealing with,
  10004. what sort of subroutine or procedure you're looking at or whatever, simply
  10005. from the syntax of the variable or subroutine name.
  10006. I believe this system is used 'in-house' at MicroSoft, though I could be
  10007. mistaken.
  10008. In any case, if anyone knows of this naming system, or knows where I can
  10009. learn it, I would greatly appreciate the information. I've been looking
  10010. for a system like this for some time, have tried unsuccessfully to come up
  10011. with my own (that I'm happy with).
  10012.                     THANKS!!!
  10013. ---------------
  10014. Following thread
  10015.  
  10016. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 335L0261 Date: 03/05/90
  10017. From: DEAN LIND                                             Time: 05:04 pm
  10018.   To: JOHN HEY (Rcvd)                                       (Read 81 times)
  10019. Subj: R: HUNGARIAN SYNTAX
  10020.  
  10021. John:
  10022.      Thank you very much for the info concerning Hungarian notation. It is
  10023. much appreciated, and I'll definately try to get my hands on a copy of
  10024. Programming Windows.
  10025. ---------------
  10026. ** Current thread: HUNGARIAN SYNTAX
  10027.  
  10028. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 335S0372 Date: 03/05/90
  10029. From: RICHARD POELING                                       Time: 11:06 pm
  10030.   To: DEAN LIND (Rcvd)                                      (Read 81 times)
  10031. Subj: R: HUNGARIAN SYNTAX
  10032.  
  10033. My interest was peaked when I read your request for Hungarian syntax, but
  10034. the person who left you the message did so privately.  Can you relay the
  10035. information he gave you to the rest of us.  thanks.
  10036. ---------------
  10037. ** Current thread: HUNGARIAN SYNTAX
  10038.  
  10039. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33AL1554 Date: 03/06/90
  10040. From: DEAN LIND                                             Time: 05:25 pm
  10041.   To: RICHARD POELING (Rcvd)                                (Read 86 times)
  10042. Subj: R: HUNGARIAN SYNTAX
  10043.  
  10044. Richard:
  10045.      They passed on the fact that in a book called Programming Windows,
  10046. published by MicroSoft, there is an explination of this syntax as it's
  10047. used at MicroSoft.
  10048. ---------------
  10049. ** Current thread: HUNGARIAN SYNTAX
  10050.  
  10051. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33AL1711 Date: 03/06/90
  10052. From: DEAN LIND                                             Time: 05:28 pm
  10053.   To: KEAN JOHNSTON (Rcvd)                                  (Read 85 times)
  10054. Subj: R: HUNGARIAN SYNTAX
  10055.  
  10056. Kean:
  10057.      THANK YOU  very much for your explination of this syntax! It is very
  10058. much appreciated and will, I'm sure, come in handy. This is just what I
  10059. was looking for!
  10060.                     Sincerely,
  10061.                          Dean Lind
  10062. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  10063.  
  10064. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 335D0190 Date: 03/05/90
  10065. From: BILL ZIMMER                                           Time: 09:03 am
  10066.   To: ALL                                                   (Read 79 times)
  10067. Subj: MS WIN & C
  10068.  
  10069. HELLO EVERYONE!,
  10070. I have a question that I haved been given conflicting answers on
  10071.  and I hope one of you has direct experience on it......
  10072. I ppresently own TurboC 2.0 and I want to start doing window's
  10073. programming, Now I know I have to have the Windows Development Kit,
  10074.  But do I need MSC? From all I have heard TurboC is much better...
  10075. and I would hate to pop for MSC if I dont need it. So the question is
  10076. can you develope MS Win. apps with TurboC or do I need MSC???
  10077.  Thanks for the help!
  10078. ---------------
  10079. Following thread
  10080.  
  10081. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 335N2017 Date: 03/05/90
  10082. From: ROBERT BALSOVER                                       Time: 07:33 pm
  10083.   To: BILL ZIMMER (Rcvd)                                    (Read 80 times)
  10084. Subj: R: MS WIN & C
  10085.  
  10086. Sorry Bill,
  10087. You'll need MSC for that.  TC and MSC deal with doubles in the same way.
  10088. I think it has something to do with MSC passing it on the NPU and TC
  10089. passes it on the stack.
  10090. Bob
  10091. ---------------
  10092. ** Current thread: MS WIN & C
  10093.  
  10094. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33AC2009 Date: 03/06/90
  10095. From: BILL ZIMMER                                           Time: 08:33 am
  10096.   To: ROBERT BALSOVER (Rcvd)                                (Read 80 times)
  10097. Subj: R: MS WIN & C
  10098.  
  10099. Thanks Bob,
  10100.    That was of course NOT the answer I wanted to hear,
  10101.  but then again... it was the answer I expected! You wouldn't
  10102. happen to know when a new version of MSC will be out do you?
  10103.  Trying to get an answer out of MS on compuserve is like pulling teeth!
  10104.  They wont even admit to a Windows 3.0 yet!
  10105.  Anyway thanks again, and if you hear of a new release of MSC
  10106. please let me know.
  10107.     Bill
  10108. ---------------
  10109. ** Current thread: MS WIN & C
  10110.  
  10111. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33AM0496 Date: 03/06/90
  10112. From: GRANT ELLSWORTH (Leader)                              Time: 06:08 pm
  10113.   To: ROBERT BALSOVER (Rcvd)                                (Read 90 times)
  10114. Subj: R: MS WIN & C
  10115.  
  10116. Bob, Are you SURE M$C is REQUIRED for Windows application development?
  10117. Seems to me that I've read some stuff about TC being used for Window
  10118. appplications (MS windows, at that) somewhere and it recent memory.
  10119.  
  10120. Also, I note that TC can be VERY effectively used to develop DesQView
  10121. active applications.  I recently finished a major application/product
  10122. project using TC and DV.  And, for all its lack of precision in its
  10123. application development documentation, I gather that DV is really a
  10124. superior product to MS Windows.  I'll confess that I have no personal
  10125. experience with MS Windows and I'm repeating some propaganda which has
  10126. appeared in several places.  Anyway, DV is an alternative to using MS
  10127. Windows and can be used with TC.  Grant
  10128. ---------------
  10129. ** Current thread: MS WIN & C
  10130.  
  10131. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33AQ3325 Date: 03/06/90
  10132. From: ROBERT BALSOVER                                       Time: 09:55 pm
  10133.   To: BILL ZIMMER (Rcvd)                                    (Read 95 times)
  10134. Subj: R: MS WIN & C
  10135.  
  10136. Bill,
  10137. Rumor has it that MS pulled MSC 6.0 from beta due to problems in their
  10138. environment.  Your guess is as good as anyone's.  Do you really have to
  10139. use MS-Windows anyway?  Deskview does alot of the same and runs anything
  10140. yo write with anyones compiler.
  10141. bob
  10142. ---------------
  10143. ** Current thread: MS WIN & C
  10144.  
  10145. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33AR0243 Date: 03/06/90
  10146. From: ROBERT BALSOVER                                       Time: 10:04 pm
  10147.   To: GRANT ELLSWORTH (Rcvd)                                (Read 97 times)
  10148. Subj: R: MS WIN & C
  10149.  
  10150. Grant,
  10151. I checked on it with the sysop's in CI$ BPROGB.  I was told it  could be
  10152. done, but no Floating point math or graphics.  I agree with you in regards
  10153. to Desqview, great package, works with any compiler, faster, great price.
  10154. .
  10155. MSC is not required to use MS-Windows, Actor, Topspeed C (I Think),
  10156. SmallTalk PM uses Presentation Manager, and Zortec C++ claim support.
  10157. And of course most Mickey-Soft compilers.
  10158. .
  10159. Bob
  10160. ---------------
  10161. ** Current thread: MS WIN & C
  10162.  
  10163. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33BB1130 Date: 03/07/90
  10164. From: BILL ZIMMER                                           Time: 07:18 am
  10165.   To: ROBERT BALSOVER (Rcvd)                                (Read 92 times)
  10166. Subj: R: MS WIN & C
  10167.  
  10168. Well,
  10169.   I would really prefer to use windows......I guess I am a bit spoiled,
  10170.  My machine is a 386 with 4 meg. I really like the TRUE multitasking in
  10171. Win/386... I really don't know enough about Deskview to comment on it,
  10172. but it has always been my impresion that it does a fine job if you dont
  10173. overload it. Also, it seems to me that windows is THE future, and if
  10174. MS ever gets off there duff and releases version 3.0, I think the windows
  10175. enviroment will be complete. At this time it is hard to defend the
  10176. interface on windows, but 3.0 should take care of that. Maybe I am
  10177. operating on some misconceptions here, if so please enlighten me!
  10178. I work in a small shop that deals exclusively with HP3000's. as such
  10179. the only way I learn about PCs is thru trial and error! At work here
  10180. I swear they use the machines as glorified type writers! I am the only
  10181. on makeing an effort to do anything about it. (by the way 386 is at my
  10182. house not work).
  10183. Thanks for your time, and I really appreciate any input you could
  10184. give me!
  10185.  Bill
  10186. ---------------
  10187. ** Current thread: MS WIN & C
  10188.  
  10189. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33BL1698 Date: 03/07/90
  10190. From: ROBERT BALSOVER                                       Time: 05:28 pm
  10191.   To: BILL ZIMMER (Rcvd)                                    (Read 84 times)
  10192. Subj: R: MS WIN & C
  10193.  
  10194. Bill
  10195. Desqview 386 is a multitasking environment.  Don't let the MS fans tell
  10196. you otherwise.  If you get the Desqview API kit, which is available at a
  10197. very reasonable price, You CAN have the pipes etc. that you expect in a
  10198. 386 operating system.  AND any compiler works with it.  It also happens to
  10199. be faster than MSWindows.  I once hoped to use MS-Windows but decided
  10200. against it not because it's a bad idea, because of who the support comes
  10201. from.  Desqview 386 is what windows 3.0 should be (IMHO).
  10202. Bob
  10203. ---------------
  10204. ** Current thread: MS WIN & C
  10205.  
  10206. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33BM0358 Date: 03/07/90
  10207. From: NESHAM SOFTWARE                                       Time: 06:05 pm
  10208.   To: ROBERT BALSOVER (Rcvd)                                (Read 83 times)
  10209. Subj: R: MS WIN & C
  10210.  
  10211.     Robert,
  10212.  
  10213.     How would Desqview handle multiple serial lines? I'm looking for
  10214. a 'cheap' environment that will take information from two or three
  10215. serial ports and write the data to disk without losing a byte.
  10216. I won't go into it any further but if you have some experience in this
  10217. area I would appreciate the response.
  10218.  
  10219.     Tim
  10220.   ps. each port will be receiving a 10byte array of information at
  10221.       120 to 300 packets per minute.
  10222. ---------------
  10223. ** Current thread: MS WIN & C
  10224.  
  10225. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33BM3477 Date: 03/07/90
  10226. From: BILL ZIMMER                                           Time: 06:57 pm
  10227.   To: ROBERT BALSOVER (Rcvd)                                (Read 78 times)
  10228. Subj: R: MS WIN & C
  10229.  
  10230. Bob,
  10231. you certainly make it sound attractive....(please excuse my spelling. it
  10232. is NOT my strong point! :-) )
  10233.    I see you use some of the compuserve fourum lingo "IMHO" , do you
  10234. go online much? Anyway back to the subject at hand....
  10235. Can desqveiw do All the things win/386 can do, such as the DDE?, One other
  10236. point can it use the 8086 virtual machine feature of the 386, as well as
  10237. protected mode? One last thing, I take it you are no fan of MS, is this
  10238. the result of one particular thing or many? Also, what is your opinion
  10239. of HP's New Wave? I myself have not had a chance to use it or even see
  10240.   it, but by all accounts it is outstanding. Can you give me some insight
  10241. into this?
  10242.    Thanks for all your help, I really appreciate your time and input!
  10243.    Bill
  10244. ---------------
  10245. ** Current thread: MS WIN & C
  10246.  
  10247. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33BP1751 Date: 03/07/90
  10248. From: GRANT ELLSWORTH (Leader)                              Time: 08:29 pm
  10249.   To: ROBERT BALSOVER (Rcvd)                                (Read 79 times)
  10250. Subj: R: MS WIN & C
  10251.  
  10252. Bob, thanks for the confirmation.  Those BI sysops and "Team Borland"
  10253. gang on CI$ are sure on the ball and really very helpful.  As I gather
  10254. from some threads I've seen from time to time, these folks just embarass
  10255. the heck out of the Mickehy-Gang on CI$.  Grant
  10256. ---------------
  10257. ** Current thread: MS WIN & C
  10258.  
  10259. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33CL3349 Date: 03/08/90
  10260. From: GRANT ELLSWORTH (Leader)                              Time: 05:55 pm
  10261.   To: ROBERT BALSOVER (Rcvd)                                (Read 80 times)
  10262. Subj: R: MS WIN & C
  10263.  
  10264. bob, re: msc 6.0 pulled from beta ....
  10265.  
  10266. Doesn't surprise me in the least.  I'm wondering if we can ever expect
  10267. a quality reliable C compiler (or other language besides ASM, where the
  10268. oops' will stare you right in the eye) from MS.  Seems like their alliance
  10269. with IBM went to their head and they have been assuming they can get away
  10270. with distributing slopware. ....  Wonder if pulling msc 6.0 in from beta
  10271. indicates that just maybe they're cleaning up the act ....  Grant
  10272. ---------------
  10273. ** Current thread: MS WIN & C
  10274.  
  10275. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33CM0517 Date: 03/08/90
  10276. From: GRANT ELLSWORTH (Leader)                              Time: 06:08 pm
  10277.   To: BILL ZIMMER (Rcvd)                                    (Read 79 times)
  10278. Subj: R: MS WIN & C
  10279.  
  10280. Bill, My recent experiences with DV and QEMM 386 have convinced me that
  10281. the DV/386 is about as true a multi=tasking environment as you'll find
  10282. that runs on top of DOS.  Windows 386 IS THE MS/IBM future.  But, I have
  10283. yet to be persuaded that IBM  + MS are going to make it the effective
  10284. standard --- rather, be able to make it the effective standard.  IBM +
  10285. MS have not been able to effectively dictate "standard systems" beyond
  10286. the bare-boned operating system itself (for pc usage anyway).  Consider,
  10287. 2 years ago, IBM + MS regurgitated OS/2 as the "wave of tomorrow!!!!".
  10288. From my reading,, I've not seen a mad rush to upgrade to OS/2, yet.  And
  10289. now, the Intel chip series 80x86 have advanced way beyond what OS/2 was
  10290. intended for.
  10291.  
  10292. Now, learning how to do WIN/386 development may be a worthwhile exercise.
  10293. The inherent problems are  not going to be very different than those of
  10294. developing for either os/2-PM or DV-386.  So, if you really wany to spend
  10295. the money and take the time to wend your way thru a possibly defective
  10296. environment, all power and patience to you.   Grant
  10297. ---------------
  10298. ** Current thread: MS WIN & C
  10299.  
  10300. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33DB1514 Date: 03/09/90
  10301. From: BILL ZIMMER                                           Time: 07:25 am
  10302.   To: GRANT ELLSWORTH (Rcvd)                                (Read 76 times)
  10303. Subj: R: MS WIN & C
  10304.  
  10305. Grant,
  10306.  Thanks for the input! Up till now all I have had to go on is some
  10307. magazine articles and P.R. from MS. In the past few days however,
  10308. I have recieved quite a bit of info from this conf. I am starting to
  10309. wonder if I should dump off Win/386 and move on to DV. I only wish
  10310. I had asked some questions here first! Now I seem to have too much
  10311. time and material invested in MS! My company has finally aproved
  10312. the Windows developement kit and MSC for purchase, I really dont know
  10313. what to do now. I guess I will have to do some heavy thinking on this.
  10314.  
  10315. As for IBM and MS, I agree that alot of people have brushed off IBM,
  10316. but I think MS still has a pretty complete control of pc OS's. While
  10317. Unix has its advantages, I cant see it becoming THE os of pc's, And
  10318. that dont leave a whole lot. Maybe I am working under some miscomceptions
  10319. on this too, so please let me know your feeling on this!
  10320. Thanks again, The last few days have been an eye opener!
  10321. Bill
  10322. ---------------
  10323. ** Current thread: MS WIN & C
  10324.  
  10325. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33DM0677 Date: 03/09/90
  10326. From: GRANT ELLSWORTH (Leader)                              Time: 06:11 pm
  10327.   To: BILL ZIMMER (Rcvd)                                    (Read 80 times)
  10328. Subj: R: MS WIN & C
  10329.  
  10330. Bill, Whatever job you are trying to do, the MSC / WIN-386 tools are not
  10331. complete losers.  They ARE usable, but there ARE problems, quality
  10332. defects, and shortcomings you will discover and work around.  The develop-
  10333. ment job will take a little longer to a lot longer, depending on your de-
  10334. bugging skills and intuitiveness with respect to isolating true causes of
  10335. problems, instead of symptoms.
  10336.  
  10337. If time to implement is of the essence AND your purchases are very recent,
  10338. many vendors will allow you to trade your stuff in for what you really
  10339. think you need.  At least I've found this to be the case with the mail-
  10340. order houses I've dealt with.
  10341.  
  10342. Cautionary note:  While DV is a good solid product and does support some
  10343. good features, the Application Developer's Tool Kit (API Library) is not
  10344. well documented.  The explanations  of when to use which function in which
  10345. sequence is confusing at best, and misleading at worst.  I spent a lot of
  10346. time in the initial phases of my recent DV/TC project just testing my
  10347. asssumptions about the behavior of several dv functions.  And QD's support
  10348. for its forum on CI$ is abysmal ... it's like a black hole from which no
  10349. matter, light, energy will emerge.  And the phone support, I'm told is
  10350. similarly abysmal.  Thus, if you depend on things like accruate precise
  10351. documentation and reliable available support, maybe the MSWIN386 would be
  10352. a little wiser --- but I have had no good experience with MS pphone
  10353. support.  The MS Docs, however, do tend to be much more precise --- even
  10354. if precisely wrong.  I don't know which is worse: a product with imprecise
  10355. documentation (DV), or one with precisely wrong info (M$Anyuthing).
  10356.  
  10357. To wrap this up ... if you've got the patience and debugging skills, you
  10358. may be better off sticking with what you've got.  If time to implement
  10359. is important, and you know how to quickly devise experiments to determine
  10360. what the software REALLY is doing vs what they didn't tell you in the
  10361. docs, then switching to TC/DV may be the better choice.  For my part,
  10362. I'd switch and take my lumps up front, rather than risk having some
  10363. obscure compiler or underlying software error come back an byte me later
  10364. so hard I couldn't move.   Grant
  10365. ---------------
  10366. ** Current thread: MS WIN & C
  10367.  
  10368. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33DR2050 Date: 03/09/90
  10369. From: ROBERT BALSOVER                                       Time: 10:34 pm
  10370.   To: GRANT ELLSWORTH (Rcvd)                                (Read 80 times)
  10371. Subj: R: MS WIN & C
  10372.  
  10373. I think that even MS can learn from A-T's mistake.  A-T thought the
  10374. end-user would accept the new dBASE, no questions asked.
  10375. ---------------
  10376. ** Current thread: MS WIN & C
  10377.  
  10378. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33DR2733 Date: 03/09/90
  10379. From: ROBERT BALSOVER                                       Time: 10:45 pm
  10380.   To: NESHAM SOFTWARE (Rcvd)                                (Read 79 times)
  10381. Subj: R: MS WIN & C
  10382.  
  10383. Tim,
  10384. I'm not sure in that one, I don't do much with serial ports.
  10385. I think there is some support for what your asking,  I won't guess because
  10386. I don't want to mislead you if I'm wrong.
  10387. Bob
  10388. ---------------
  10389. ** Current thread: MS WIN & C
  10390.  
  10391. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33DS0446 Date: 03/09/90
  10392. From: ROBERT BALSOVER                                       Time: 11:07 pm
  10393.   To: BILL ZIMMER (Rcvd)                                    (Read 79 times)
  10394. Subj: R: MS WIN & C
  10395.  
  10396. Bill,
  10397. I don't do anything differently with DV than in the normal environment.
  10398. You can have your programs communicate with each other etc. but I don't
  10399. usually get into that.  The reason to use DV is that your programs _don't_
  10400. have to be written different and you don't need to purchase a $300 package
  10401. in addition to the normal DV package as you do with MS-Windows.
  10402. .
  10403. I'm on CI$ daily, mostly in BPROGB but now I'll spend more time in PCVENB
  10404. because PDC Prolog is there now.(PDC is the new Turbo Prolog).  DV is also
  10405. in PCVENB.
  10406. .
  10407. I don't use MSC because when you tell them about a bug, they'll sometimes
  10408. tell you a work-around, not post a patch.  Borland usually posts a patch
  10409. if one is required and they have always responded _VERY_ quickly if I had
  10410. a problem.  Also, I think TC is faster than MSC.  The real test is not to
  10411. look at Borlands bench marks, not to look at MS bench marks, look at
  10412. Zortech's, look at JPI's (Top Speed C) bench marks.  They show is faster
  10413. in most of the test over MSC.  Also, I can't remember if it was in IBMPRO
  10414. or BPROGB but someone ran a test of the fp library and found MSC's
  10415. routines did not give accurate results, so even if MSC produces slightly
  10416. faster math functions they're of no value to me if they sacrificed
  10417. accuracy to do it. On second thought it might have been the latest DDJ.
  10418. .
  10419. Bob
  10420. ---------------
  10421. ** Current thread: MS WIN & C
  10422.  
  10423. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33EE1235 Date: 03/10/90
  10424. From: BILL ZIMMER                                           Time: 10:20 am
  10425.   To: GRANT ELLSWORTH (Rcvd)                                (Read 78 times)
  10426. Subj: R: MS WIN & C
  10427.  
  10428. Grant,
  10429.  Well you certainly have given me a lot to think about!
  10430.  I guess my biggest worry is where the leads in business terms. DV seems
  10431. to the backing of most pc programmers where as Windows seems to have
  10432. high level corperate support. This is turning into a bigger can of worms
  10433. then I anticipated. While my debugging skills are not awesome I do have
  10434. a fair understanding of the skills involved. Time on the other hand,
  10435. is NOT a major concern. When I sold my company on the idea of moving
  10436. some of the applications and data off the mainframe and onto pc's
  10437. there additude was very conservative, more of a 'let him try it, but lets
  10438. go real slow' additude then anything else. While I would liike to be able
  10439. to churn out picture perfect code in a flash, I am quite a bit more
  10440. realistic then that! I realize that either path I take, there are going to
  10441. be ruff spots. Now I just have to decide if I want the trouble up front
  10442. or down the road a bit. Quite a dilema.
  10443.  As I said before, you have given me ALOT to think about. I think it
  10444.  would be wise for me to just slow down a bit and look at the big picture,
  10445.  as you kind of implied....I do tend to leap without looking as it were,
  10446. and I think it is high time I got out of this habbit. I am just glad
  10447. I took the time to ask some question here. All of you have been a
  10448. great help, and I think I will be asking quite a bit more in the very near
  10449. future. I hope that no one will get impatient with me. I seem to ask some
  10450. pretty lame questions at times, but as I said before I know anyone
  10451. personally who works with pc's, and you guys have been more help in a
  10452. couple of day's  then all the article's I've read in the last few months!
  10453.  
  10454.    Thank's again for all your help, and if you have any other ideas or
  10455. comments please let me know!
  10456.      Greatfully,
  10457.         Bill
  10458. ---------------
  10459. ** Current thread: MS WIN & C
  10460.  
  10461. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33EE2721 Date: 03/10/90
  10462. From: BILL ZIMMER                                           Time: 10:45 am
  10463.   To: ROBERT BALSOVER (Rcvd)                                (Read 79 times)
  10464. Subj: R: MS WIN & C
  10465.  
  10466. Hmmmm,
  10467.  I just got the latest DDJ, I will look thru it for that. I also just
  10468. recieved the latest BYTE. MS has just released MSC 6.0, It got a good
  10469. write up but it is _VERY_ large. The person writing the article said
  10470. it took up 8 MEG on his HD, and that was JUST for the small mem mod.
  10471.  From all I know of MS, this seems typical!
  10472. I used to spend a fair amount of time on CI$, but as we all know
  10473. the connect charges can kill you! Now  I log on go to what I want
  10474. check out and get off as quick as poss. I have signed up for Prodigy,
  10475.  as they sent me an offer I cant refuse. They will give you the software
  10476. needed for free as well as a free month to check it out. If you decided
  10477.  to stay with them, it is only $9.95 a month period. No connect fee's
  10478.  or any other chargeson paper anyway!). I dont know if it has all the
  10479. major vendors that CI$ has but it's worth taking a look at!
  10480.  Enough of that. I have come to the decision to not make a decision
  10481. quite yet. As I have found out from talking to people in this conf.,
  10482.   this is not something to jump into without looking! I thank you very
  10483. much for help and time. I hope you dont get impatient with me if I
  10484. seem to ask alot of simple questions! I really appreciate or time
  10485.  and help! You wouldn't happen to know COBOL would you? I seem to
  10486.  get hung up tring to translate everything C to COBOL in my head.
  10487.  This does not work out, to say the least! I guess I do it because
  10488.  I am more familiar with cobol then c. I hope I get over soon!
  10489.   Thanks again, and if you have anymore comment or suggestions, please
  10490. dont hesitate to let me know. If it wern't for you guys my wallet would
  10491. be alot lighter without much to show for it!
  10492.  Bill
  10493. ---------------
  10494. ** Current thread: MS WIN & C
  10495.  
  10496. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33EG0796 Date: 03/10/90
  10497. From: ROBERT BALSOVER                                       Time: 12:13 pm
  10498.   To: BILL ZIMMER (Rcvd)                                    (Read 78 times)
  10499. Subj: R: MS WIN & C
  10500.  
  10501. Bill,
  10502. Are you refering to the March '90 issue of BYTE?  I think that was just a
  10503. review of the beta and not a release announcement.  If I'm wrong I'm sure
  10504. one of the lurkers will point that out.
  10505. .
  10506. Bill, if you use TAPCIS it will save you big bucks!  My bill was creeping
  10507. up to the $200 mark before I started using it, this month it's estimating
  10508. a $50 bill and I'm on more forems now.  If you want to save online time,
  10509. I'll zmodem it to you if you live here in the Milwaukee area.
  10510. .
  10511. 'Got that Prodigy mailing myself, I haven't decided if I'll blow $9 on it
  10512. yet.  I think it sounds to good to be true, I wonder where the hidden
  10513. costs are.  If you get online with it soon, please let me know what you
  10514. think about it.
  10515. .
  10516. Sorry I forgot COBOL at the earliest opportunity.  Please don't get the
  10517. wrong idea, COBOL is a useful tool, I just wanted to narrow my
  10518. concentration to what I use, avoiding 'a jack of all trades, a master at
  10519. none.'.  What are you trying to do in C anyway?
  10520. Don't feel bad about your difficulty moving between languages, if your up
  10521. for a real challenge try PROLOG, that will have you beating your head
  10522. against the keyboard!
  10523. Bob
  10524. ---------------
  10525. ** Current thread: MS WIN & C
  10526.  
  10527. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33EG3381 Date: 03/10/90
  10528. From: GRANT ELLSWORTH (Leader)                              Time: 12:56 pm
  10529.   To: BILL ZIMMER (Rcvd)                                    (Read 76 times)
  10530. Subj: R: MS WIN & C
  10531.  
  10532. Bill, If you are attempting a "downsize" from mainframe, you already have
  10533. at least one foot in the cow pie.  To choose tools not well received in
  10534. mainframe computing institutional circles (e.g. tools not sold by Micro-
  10535. slop, IBM, etc..) is putting the other foot in the pie.  Rugged.
  10536.  
  10537. Don't know quite what I'd do in your place.  But, I DO have some similar
  10538. experience to report.  I'm an old-line mainframer ALC systems developer
  10539. and recently was given an ambiguous PC based development problem to get
  10540. the corporate tush out of hot spot.  I chose TC, not M$C 5.x.  We had no
  10541. choice in the DV/MS-WIN386 area.  Our co-developer co-marketer
  10542. organization had already chosen and comitted to DV AND M$C (
  10543. "because it was the industry standard ....").  The other organization and
  10544. I agreed that my organization could proceed with TC because DV support/
  10545. access from TC was possible and not problematic.  So we proceeded.  The
  10546. problems I had with DV docs I've noted elsewhere in this thread and will
  10547. not repeat here.  Anyway, part of our project involved using special
  10548. hardware device-driver libraries.  I find out at the last minute (i.e.
  10549. after I had written and debugged most of my "shell" code), that the 3rd
  10550. party libs were available ONLY FOR M$C support.  THere were 2 sets
  10551. involved.  One vendor genned a set of TC Libs for us to use.  The other
  10552. has yet to respond.  The vendor who genned the TC libs claims they are
  10553. NOT going to support "Toy" (non-standard) libraries and the TC stuff was a
  10554. deviation from course.  That is, I got the libs I need, but I don't get
  10555. support or upgrades or any fixes --- I am seeing ALL I am going to get.
  10556. (THese guys are gonna get clubbed and may be "persuaded" to support TC).
  10557. The 2nd vendor will be more difficult ---- and that group may be more
  10558. important.
  10559.  
  10560. So, here I've now got a hybrid system --- with sections built on
  10561. quicksand (unsupported libs).  And a MUST have M$C just in case spooks
  10562. show up in the software we have to use with the 2nd vendors library.
  10563.  
  10564. Well, you'd think I'd be out pounding the pavement over this ....I got
  10565. yelled at for my anti-"standard" bias --- but when I showed evidence of
  10566. the M$C time-consuming bugs ... the story changed.  Now, the accepted rule
  10567. of conduct is: I ain't distributing ANY of of our software compiled in M$C
  10568. unless there is no other choice.
  10569.  
  10570. Having to buy the 2 comipilers was embarassing.  But not fatal.
  10571.  
  10572. Since the cost of these tools are relative marginal in mainframe s/w cost
  10573. terms, you might be able to get all 4 sets (TC M$C DV, MSWIN) and claim
  10574. that you must do some real development with each to assess which is the
  10575. better tool set for your shop.  It's a little slippery, but it might fly.
  10576.  
  10577. Grant
  10578. ---------------
  10579. ** Current thread: MS WIN & C
  10580.  
  10581. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33FD2473 Date: 03/11/90
  10582. From: BILL ZIMMER                                           Time: 09:41 am
  10583.   To: ROBERT BALSOVER (Rcvd)                                (Read 78 times)
  10584. Subj: R: MS WIN & C
  10585.  
  10586. Bob,
  10587.  Yes I live in Milwaukee, down on the south side in Bay view, near
  10588. South Shore park. TAPICS, Huh?, It sounds real familiar but I cant place
  10589. it! I hear you about the bills, it sounds like my own story, if I could
  10590. get
  10591. a simular drop in price I'd be VERY interested in it. Let me know what
  10592. to do to get it from you!  As for Prodigy, I thout it sounded a bit too
  10593. good to be true also, but it thru big blue and Sears so i going to give it
  10594. a shot, I'll keep you updated!
  10595.  About COBOL, I dont blame you you for forgetting it at the earliest time
  10596. poss., That is part of the reason I'm breaking into C. It can be very
  10597. frustrating to even the most seemingly simple thing with it. Such as
  10598. simple graphics!
  10599.  As for what I am Tring to....That is a bit more complicated, I have two
  10600. seperate agendas, one for work and one for myself...
  10601. Let me start with work. What we do is process medical claims for some
  10602. local IPA's. This involves more then just simple data entry. I maintain]
  10603. several VERY large databases on the HP3000, for the members, claims,
  10604. diagnosis code, procedure codes, doctors...Ect. From this we not only
  10605. pay the claims but must produce some rather extensive finacial reports
  10606. and other misc reports. I feel that a major portion of the reporting,
  10607.  and analisis could be done on pc's. It is a bit more involved then that
  10608. but it souldn't be that bad, once
  10609. I decide what path to take!
  10610.  For myself, I would like to design a very realistic simulation of
  10611. military actions in Europe......I know a rather frivolous activity bbut
  10612. I am a military buff, and I have yet to see a real good simulation on the
  10613. market. Anyway that about covers its. Let me know about this TAPICS thing
  10614.  ok? Thanks in advance!
  10615.    Bill
  10616.  
  10617. P.S sorry about all the typo's and spelling, I wasn't quite awake yet!
  10618. ---------------
  10619. ** Current thread: MS WIN & C
  10620.  
  10621. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33FD3568 Date: 03/11/90
  10622. From: BILL ZIMMER                                           Time: 09:59 am
  10623.   To: GRANT ELLSWORTH (Rcvd)                                (Read 77 times)
  10624. Subj: R: MS WIN & C
  10625.  
  10626. Grant,
  10627.  I think you read my mind! I was thinkingg about this last night and
  10628. came up with about the same conclusion. I already have TC 2.0 pro ( my
  10629. own purchase), and they have already approved the purchase of M$C as well
  10630. as Win development kit, That only leaves DV, and  I think I can convince
  10631. the to spring for it. Your right about going against the flow where
  10632. M$ and Win are concerned, HP has alreay said they wont support or
  10633. help with any of our pc projects unless we use "approved" products, i.e.
  10634.  M$C, Win, and New Wave. I actually look forward to working with NW, from
  10635. all I have heard, it is real kind to developers. By combining the
  10636. different products I could come out of this smelling like a rose.....or
  10637. hip deep in sh**. Lets hope for the former!
  10638. Now correct me if i am wrong on this point..., I should be able to do a
  10639. good portion of coding thru TC as well as the debugging (from what I have
  10640. heard Borland debugger blow away MS's especially on a 386), Then port
  10641. the incompatible parts thru M$C...... Or would this be more hassles then
  10642. it worth?  Also, are there any tools out there to convert from TC to M$C?.
  10643.     Thank for your time, and let me know what you think.
  10644.  Bill
  10645. ---------------
  10646. ** Current thread: MS WIN & C
  10647.  
  10648. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33FH0448 Date: 03/11/90
  10649. From: DENNIS DODSON                                         Time: 01:07 pm
  10650.   To: ROBERT BALSOVER (Rcvd)                                (Read 77 times)
  10651. Subj: R: MS WIN & C
  10652.  
  10653. Bob,
  10654. I`ve read about that Prodigy offer in the paper and it sounds like
  10655. something I'd like to check out.  I did not receive a mailing. Is
  10656. it possible to register via modem/PC ?  If so, I would appreciate
  10657. you posting the phone number.  Thanks in Advance.  -Dennis-
  10658. ---------------
  10659. ** Current thread: MS WIN & C
  10660.  
  10661. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33FK2327 Date: 03/11/90
  10662. From: GRANT ELLSWORTH (Leader)                              Time: 04:38 pm
  10663.   To: BILL ZIMMER (Rcvd)                                    (Read 80 times)
  10664. Subj: R: MS WIN & C
  10665.  
  10666. Bill, Just for the record, I converted my TC code developed for the DV
  10667. application to MSC with only minor problems.  The conversion to MSC DID
  10668. uncover a couple of subtle (and real stoopid) coding errors on my part.
  10669. The major glitches to look out for are:
  10670.  
  10671. o DOS_Specific function calls are different in the 2 compilers
  10672. o Macros/Functions such as FP_SEG work quite different in each
  10673. o M$C's optimizations can be disastrous and obscure
  10674.   DO NOT USE INTRINSIC FUNCTIONS or RELAXED ALIAS CHECKING under any
  10675.   circumstances --- unless you enjoy chasing compiler anomalies
  10676. o TC has some native functions which have no M$C equivalents --- such
  10677.   as delay(), clrscr(), xxxcoreleft()
  10678.  
  10679.   On (far)coreleft(),,,, while the surface docs suggest that _memavl()
  10680.   is equivalent, it ain't.  Best bet is to jury-rig a freect() based
  10681.  computation
  10682.  
  10683. o M$C has an insanely low limit on declared string size of 512, TC has
  10684.   no documented limit
  10685.  
  10686.   char * my_string = " ..... "
  10687.       (limited to 512 chars/bytes in the pay_more get_less compiler)
  10688.  
  10689. Almost all differences can be handled with macros.  The few that can't
  10690. are those where the functional results require very different logic in
  10691. each compiler --- e.g. constructing a far pointer on the fly.
  10692.  
  10693. Otherwise I'd describe a TC <---> M$C conversion as a little bumpy, but
  10694. not exceptionally rocky.  For time estimating purposes, I'd factor in
  10695. about 1 day for each 750 lines or so of code.  High would be 1500, messy
  10696. and low is 500 per day.  Avoiding low level functions increases the cross-
  10697. compiler compatiblity.  Clever macro writing helps.  Pre-recognizing and
  10698. "homogenizing" areas where the compilers behave a little different or have
  10699. different function names and results -- e.g. _dos_read() (M$C) vs _read()
  10700. (or read()) (TC) --- helps.
  10701.  
  10702. In general, except for very small applications or systems, I think you'll
  10703. find the overall development time sufficiently faster with TC that any
  10704. time spent to convert proven+debugged results to M$C will make the total
  10705. less than to have suffered m$c all the way through.
  10706.  
  10707. grant
  10708. ---------------
  10709. ** Current thread: MS WIN & C
  10710.  
  10711. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33FP0382 Date: 03/11/90
  10712. From: ROBERT BALSOVER                                       Time: 08:06 pm
  10713.   To: DENNIS DODSON (Rcvd)                                  (Read 79 times)
  10714. Subj: R: MS WIN & C
  10715.  
  10716. Dennis,
  10717. 1 800 822-6922 Ext. 696
  10718. Bob
  10719. I believe that is a voice #.
  10720. ---------------
  10721. ** Current thread: MS WIN & C
  10722.  
  10723. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33GB1148 Date: 03/12/90
  10724. From: BILL ZIMMER                                           Time: 07:19 am
  10725.   To: GRANT ELLSWORTH (Rcvd)                                (Read 75 times)
  10726. Subj: R: MS WIN & C
  10727.  
  10728. Grant,
  10729. Thanks for the info! I captured you letter to disk and will keep it
  10730. handy. From all I have heard it will be easier to do the development
  10731. in TC then port it to M$C, so I guess that is what I'll do!
  10732.   You have been a GREAT help, thanks again!
  10733.    Bill
  10734. ---------------
  10735. ** Current thread: MS WIN & C
  10736.  
  10737. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33HE1879 Date: 03/13/90
  10738. From: DENNIS DODSON                                         Time: 10:31 am
  10739.   To: ROBERT BALSOVER (Rcvd)                                (Read 80 times)
  10740. Subj: R: MS WIN & C
  10741.  
  10742. Bob,
  10743. Please re-send that phone no.  I am sure I am not the one you intended
  10744. to send to.  -Dennis-
  10745. ---------------
  10746. ** Current thread: MS WIN & C
  10747.  
  10748. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33HP1902 Date: 03/13/90
  10749. From: ROBERT BALSOVER                                       Time: 08:31 pm
  10750.   To: DENNIS DODSON (Rcvd)                                  (Read 82 times)
  10751. Subj: R: MS WIN & C
  10752.  
  10753. Dennis,
  10754. Sorry about that.  It did get to the intended person.  I wonder it came to
  10755. you, I sent it private.
  10756. Bob
  10757. ---------------
  10758. ** Current thread: MS WIN & C
  10759.  
  10760. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33IF3179 Date: 03/14/90
  10761. From: DENNIS DODSON                                         Time: 11:53 am
  10762.   To: ROBERT BALSOVER (Rcvd)                                (Read 80 times)
  10763. Subj: R: MS WIN & C
  10764.  
  10765. EMBARASSED !!! Sorry Bob, I had forgot that I had asked you for that
  10766. Prodigy number !  What jogged my mind is that today I received the
  10767. mailing that you guys had been talking about.  Belated thanks for
  10768. the phone number.  -Dennis-
  10769. ---------------
  10770. ** Current thread: MS WIN & C
  10771.  
  10772. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33IH0466 Date: 03/14/90
  10773. From: ROBERT BALSOVER                                       Time: 01:07 pm
  10774.   To: DENNIS DODSON (Rcvd)                                  (Read 78 times)
  10775. Subj: R: MS WIN & C
  10776.  
  10777. Dennis,
  10778. No problem.  I often forget what a question was by the time a reply comes
  10779. back, a hazard of telecommunications.
  10780. Bob
  10781. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  10782.  
  10783. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33AD1007 Date: 03/06/90
  10784. From: IDC EMAIL                                             Time: 09:16 am
  10785.   To: ALL                                                   (Read 77 times)
  10786. Subj: GREEN PROGRAMMER SEEKS HELP...
  10787.  
  10788. Good day-
  10789.  
  10790. I am a novice C programmer, and am sincerely fustrated with the Microsoft
  10791. C manuals.  I need a routine to borrow from.  I am trying to read in ASCII
  10792. quote-comma delimited data, determine if that line of data is the one I
  10793. want to use (does that element = my variable) then fill an array with that
  10794. line of data.  I have almost everything else done but the file I/O part.
  10795. Could someone point me to a routine which will read a file in which the
  10796. data is seperated with { "," }?  There must be a ton of em out there (I
  10797. have tried downloading a number of routines from the Mahoney collection
  10798. with no success).  Your help is most sincerely appreciated!
  10799.  
  10800. Brett (IDC EMAIL)
  10801. ---------------
  10802. Following thread
  10803.  
  10804. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34UE3224 Date: 04/25/90
  10805. From: STEVE HOVEY                                           Time: 10:53 am
  10806.   To: IDC EMAIL (Rcvd)                                      (Read 75 times)
  10807. Subj: R: GREEN PROGRAMMER SEEKS HELP...
  10808.  
  10809. altho ihavent had a need to use this command... (and im sure micrsoft c
  10810. has it) .. if your delimited file has a constant number of fields perline
  10811. you mite try using fscanf();
  10812.  
  10813. the patter you use in fscanf determines what is considered field
  10814. seperators (i believe) so for a 5 field file you mite code
  10815.  
  10816. using fscanf... check ur manual on this command... i dont want to give an
  10817. example and be wrong... maybe someone else is more familiar with this?
  10818. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  10819.  
  10820. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33CR3010 Date: 03/08/90
  10821. From: DENNIS DODSON                                         Time: 10:50 pm
  10822.   To: ALL                                                   (Read 77 times)
  10823. Subj: C ARITHMETIC - STUMPED
  10824.  
  10825. 9I'm having a problem with a new report program I am writing.  I can't
  10826. seem to figure out (with C) how to correctly calculate a simple
  10827. percentage amount.  The result is coming out as 78.88- on the report
  10828. (that's an edited figure from a print toolkit, so I assume the 'long'
  10829. result is really 7888-.  I have not done much arithmetic coding with C
  10830. so I would appreciate any help.  The desired result should be 78010,
  10831. toolkit print edited to 780.10 .
  10832.  
  10833. Here is the scenario:
  10834.  
  10835. int pct;               /* 7.510% stored as int 07510 */
  10836. long amount;           /* $10,387.53 stored as long 1038753 */
  10837. long result;
  10838.  
  10839. result = ( (double) (amount * pct) * .00001);
  10840.  
  10841. Don't laugh, this does seem to work with smaller amounts, but when I
  10842. began testing with larger amounts, I got undesired results.  What I'm
  10843. looking for is to keep everything in 'pennies' and at print time do
  10844. something like multiply times .01 in my toolkit picture edit routine
  10845. to come up dollars and cents.
  10846.  
  10847. -Dennis-
  10848.  
  10849.  
  10850. ---------------
  10851. Following thread
  10852.  
  10853. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33DA0181 Date: 03/09/90
  10854. From: TOM FRANK                                             Time: 06:03 am
  10855.   To: DENNIS DODSON (Rcvd)                                  (Read 80 times)
  10856. Subj: R: C ARITHMETIC - STUMPED
  10857.  
  10858. Dennis,
  10859.  
  10860. You might want to move the cast inside your expression - as it stands the
  10861. long time the int is done and THEN cast to a double - the numbers you have
  10862. are too big for the standard INTEL long.  Try something like:
  10863.  
  10864.     result = ((double)amt * (double)pct) * .000001
  10865.  
  10866. You have to remember that C only does conversions as required by the items
  10867. being worked on at the time - not based on the destination or other
  10868. factors - like your double applied to the result.
  10869.  
  10870. Tom
  10871. ---------------
  10872. ** Current thread: C ARITHMETIC - STUMPED
  10873.  
  10874. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33DH1380 Date: 03/09/90
  10875. From: DENNIS DODSON                                         Time: 01:23 pm
  10876.   To: TOM FRANK (Rcvd)                                      (Read 75 times)
  10877. Subj: R: C ARITHMETIC - STUMPED
  10878.  
  10879. Thanks for the help Tom, will try your suggestion today.....Dennis
  10880. ---------------
  10881. ** Current thread: C ARITHMETIC - STUMPED
  10882.  
  10883. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33FH1418 Date: 03/11/90
  10884. From: DENNIS DODSON                                         Time: 01:23 pm
  10885.   To: TOM FRANK (Rcvd)                                      (Read 71 times)
  10886. Subj: R: C ARITHMETIC - STUMPED
  10887.  
  10888. Tom,
  10889. Thanks for the mini-education.  The calculation works like a champ.  I
  10890. suppose if I want to round, I could add .005 addition to the right side
  10891. of the formula.  Thanks again for the help.
  10892. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  10893.  
  10894. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33DA0499 Date: 03/09/90
  10895. From: JOHN ABATTE                                           Time: 06:08 am
  10896.   To: ALL                                                   (Read 76 times)
  10897. Subj: FP_SEG MACRO
  10898.  
  10899.  
  10900.     I have a question regarding the use of the FP_SEG macro in Turbo C.
  10901. I came across some source listings in the "DOS Developers Guide" for
  10902. accessing EMS, and when I try to compile them with Turbo C I get the
  10903. error "Lvalue required in function...". There are four functions
  10904. altogether in the listing that generate that message, and all are of the
  10905. form shown below, where FP_SEG(*pfa) is on the left side of the
  10906. assignment operator.
  10907.  
  10908.   /* Returns far address of EMM page frame */
  10909. int em_get_far_adr(char far **pfa)
  10910. {
  10911.   in.h.ah = 0x41;             /* EMS get page frame address function */
  10912.   status = ((unsigned int) int86(0x67, &in, &out) >> 8);
  10913.   if (!status)
  10914.   {
  10915.     FP_SEG(*pfa) = out.x.bx;  /* THIS LINE PRODUCES THE ERROR! */
  10916.     FP_OFF(*pfa) = 0;         /* No errors for this line */
  10917.   }
  10918.   return status;
  10919. }
  10920.  
  10921.     When I compile under MSC 5.1, no errors or warnings are produced. I
  10922. suspect it may have something to do with Turbo's MK_FP macro being
  10923. needed. I notice that MSC has no equivalent to MK_FP.
  10924.  
  10925.     If anyone has any ideas I'd appreciate hearing them. I'm not
  10926. familiar enough with the proper useage of these macros so I haven't been
  10927. able to figure out how to fix these function to work with TC.
  10928.  
  10929. Thanks in advance...John.
  10930.  
  10931. ---------------
  10932. Following thread
  10933.  
  10934. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33DL3160 Date: 03/09/90
  10935. From: GRANT ELLSWORTH (Leader)                              Time: 05:52 pm
  10936.   To: JOHN ABATTE (Rcvd)                                    (Read 77 times)
  10937. Subj: R: FP_SEG MACRO
  10938.  
  10939. John, FP_SEG is an MSC device ... not TurboC.  Whaat you probably will
  10940. have to do is use the TC analogy, MAKE_FP ... as follows:
  10941.  
  10942.   *pfa = MAKE_FP(out.x.bx,0);
  10943.  
  10944. If you need to make TC/MSC cross-compiler compatiblity possible, use the
  10945. TC predefined macro variable, __TURBOC__ to determine which compiler is
  10946. active and generate the appropriate line(s) of code.  Grant
  10947. ---------------
  10948. ** Current thread: FP_SEG MACRO
  10949.  
  10950. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33EK2156 Date: 03/10/90
  10951. From: JOHN ABATTE                                           Time: 04:35 pm
  10952.   To: GRANT ELLSWORTH (Rcvd)                                (Read 74 times)
  10953. Subj: R: FP_SEG MACRO
  10954.  
  10955. Thanks for the help, Grant. I suspected that I may need to use the MK_FP
  10956. in TC, but I wasn't too sure. I'll try your suggestion and see how it
  10957. goes.
  10958. Thanks again...John.
  10959. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  10960.  
  10961. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33GC3283 Date: 03/12/90
  10962. From: TODD SAHBA                                            Time: 08:54 am
  10963.   To: ALL                                                   (Read 74 times)
  10964. Subj: QUICKC ASSEMBLER
  10965.  
  10966. Hi folks.  I am rather new to C programming, and am working with Micro
  10967. softs Quick C.  One thing I was having some trouble figuring out is how to
  10968. get the compiler to list assembly code.  I have noticed that when I
  10969. compile, I'll get a message from the compiler saying "File List: [NUL]"
  10970. How can I change that to a file name for the assembly code.  Thanks for
  10971. your help.
  10972. ---------------
  10973. Following thread
  10974.  
  10975. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33GQ1496 Date: 03/12/90
  10976. From: ROBERT BALSOVER                                       Time: 09:24 pm
  10977.   To: TODD SAHBA (Rcvd)                                     (Read 77 times)
  10978. Subj: R: QUICKC ASSEMBLER
  10979.  
  10980. Todd,
  10981. I don't have Quick C, but do have MASM.  It appears that QC is offering
  10982. you a default output device. If, at that file list: prompt you type in a
  10983. file name maybe it will list it there.  I think thats how MASM does it.
  10984. Bob
  10985. ---------------
  10986. ** Current thread: QUICKC ASSEMBLER
  10987.  
  10988. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33HD0979 Date: 03/13/90
  10989. From: TODD SAHBA                                            Time: 09:16 am
  10990.   To: ROBERT BALSOVER (Rcvd)                                (Read 78 times)
  10991. Subj: R: QUICKC ASSEMBLER
  10992.  
  10993. Thanks for your reply.  Actually though, that is the problem.  The "File
  10994. List" message is not a prompt, just a message from the compiler.  The
  10995. thing is, it leads me to believe it is possible for it to be something
  10996. other than "[NULL]" - otherwise why bother haveing the compiler send the
  10997. message in the first place.  I don't know if my thinking is correct or
  10998. not, but it makes sense.  Fortunatly I have found a way around this.  I
  10999. compile my program, link , then use a disassembler.  The problem with this
  11000. is that I loose my symboles in the process.  Thanks for your help.
  11001. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  11002.  
  11003. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33HE2009 Date: 03/13/90
  11004. From: DENNIS DODSON                                         Time: 10:33 am
  11005.   To: ALL                                                   (Read 86 times)
  11006. Subj: STRING MANIPULATION HELP
  11007.  
  11008. Does anyone out there have a C source routine they could upload and
  11009. share with me to take a string of first name, sometimes middle initial,
  11010. and last name and break this to two strings consisting of a first name
  11011. and middle initial string and a last name string.  For example:
  11012.  
  11013.  INPUT: char name[39];      OUTPUT: char lname[16];   char fname[15];
  11014. -----------------------    -------------------------------------------
  11015.   "DENNIS R DODSON"                   "DODSON"          "DENNIS R"
  11016.   "DENNIS R. DODSON"                  "DODSON"          "DENNIS R."
  11017.   "DENNIS DODSON"                     "DODSON"          "DENNIS"
  11018.  
  11019. Any help would be appreciated.
  11020. -Dennis-
  11021. ---------------
  11022. Following thread
  11023.  
  11024. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33HQ2427 Date: 03/13/90
  11025. From: GLEN THOMPSON                                         Time: 09:40 pm
  11026.   To: DENNIS DODSON (Rcvd)                                  (Read 84 times)
  11027. Subj: R: STRING MANIPULATION HELP
  11028.  
  11029. Dennis,
  11030.  
  11031. I don't have a routine handy but here's a possible solution:
  11032.  
  11033. Position a pointer to the last non-blank character in the input string.
  11034. Step backwards through the string until a blank is found.  From that point
  11035. to the end is the last name and everything from the start to the end is
  11036. the first name and middle initial.
  11037.  
  11038. I'd try to write you a code sample but I'm too tired right now and would
  11039. probably mess it up.
  11040.  
  11041. glen
  11042. ---------------
  11043. ** Current thread: STRING MANIPULATION HELP
  11044.  
  11045. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33IF2289 Date: 03/14/90
  11046. From: DENNIS DODSON                                         Time: 11:38 am
  11047.   To: GLEN THOMPSON (Rcvd)                                  (Read 84 times)
  11048. Subj: R: STRING MANIPULATION HELP
  11049.  
  11050. Glen,
  11051. Thanks for the response.  I understand what is to be done, have been
  11052. programming for 20 years in COBOL, RPG, other proprietary, etc.  But
  11053. am not too sharp with C and really want to see HOW IT SHOULD BE DONE.
  11054. Thought maybe that someone in a C business application environment would
  11055. have a 'Canned' function written that they could share with me.  Oh well,
  11056. will have to wait and see if any more respone.  Thank again.
  11057. -Dennis-
  11058. ---------------
  11059. ** Current thread: STRING MANIPULATION HELP
  11060.  
  11061. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33IL2988 Date: 03/14/90
  11062. From: GRANT ELLSWORTH (Leader)                              Time: 05:49 pm
  11063.   To: DENNIS DODSON (Rcvd)                                  (Read 80 times)
  11064. Subj: R: STRING MANIPULATION HELP
  11065.  
  11066. Dennis, I have a general purpose set of subroutines for decoding (parsing)
  11067. names out of mailing labels (among other things).  Unfortunately, the
  11068. routines were written in PASCAL --- not C.  Even so, the principals of
  11069. un-scrambling a name are the same.  The routines worked something like
  11070. what Glen suggested, but also asccounted for such oddities as:
  11071.  
  11072.    James St. John
  11073.    Jean Saint Louise
  11074.    Gene de Guerre
  11075.    La Verne de la Grazia
  11076.  
  11077. and it did some "approximaate" case translation if the labels happend to
  11078. be in all capital letters.  If you are interested, let me know and we
  11079. can discuss how you can get the subroutine set.
  11080.  
  11081. I really haven't the time right now to transliterate them to a proper C
  11082. form.
  11083.  
  11084. Grant
  11085. ---------------
  11086. ** Current thread: STRING MANIPULATION HELP
  11087.  
  11088. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33IL3406 Date: 03/14/90
  11089. From: GRANT ELLSWORTH (Leader)                              Time: 05:56 pm
  11090.   To: DENNIS DODSON (Rcvd)                                  (Read 82 times)
  11091. Subj: R: STRING MANIPULATION HELP
  11092.  
  11093. Dennis, I have an idea for you.  Why don't you come up with something ---
  11094. giving it your best shot ... and making it available for  commentary.
  11095.  
  11096. BTW, the PASCAL version I mentioned in previous msg was not the first time
  11097. I had to do that sort of thing.  The first time I had to write such string
  11098. manipulation code was "long ago" ... and I had to do in the nemisis
  11099. (C***L) .   Ever since then, I have been a C***L eradication fanatic.
  11100. NOTE: The C***L I used predated the STRING/UNSTRING pseudo=verbs.
  11101.  
  11102. Thus. if you can conceptualize how you would solve the problem in C***L,
  11103. the transference to C should be fairly straight-forward.
  11104.  
  11105. Grant
  11106. ---------------
  11107. ** Current thread: STRING MANIPULATION HELP
  11108.  
  11109. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33JA3256 Date: 03/15/90
  11110. From: DENNIS DODSON                                         Time: 06:54 am
  11111.   To: GRANT ELLSWORTH (Rcvd)                                (Read 80 times)
  11112. Subj: R: STRING MANIPULATION HELP
  11113.  
  11114. Grant, I like that idea.  I will try to post up some code by Monday.
  11115. I really know what to do (also have been a C***l user, just recent-
  11116. ly converted to C), but want to know HOW TO REALLY DO IT properly
  11117. with C (boy its tough coming from the C***L world!).  Thanks for
  11118. the advice.  -Dennis-
  11119. ---------------
  11120. ** Current thread: STRING MANIPULATION HELP
  11121.  
  11122. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33JL2390 Date: 03/15/90
  11123. From: GRANT ELLSWORTH (Leader)                              Time: 05:39 pm
  11124.   To: DENNIS DODSON (Rcvd)                                  (Read 85 times)
  11125. Subj: R: STRING MANIPULATION HELP
  11126.  
  11127. Dennis, If you DO upload something, be SURE to leave me a msg to get my
  11128. attention with details.  Grant
  11129. ---------------
  11130. ** Current thread: STRING MANIPULATION HELP
  11131.  
  11132. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33LS1402 Date: 03/17/90
  11133. From: OTTO PORTER                                           Time: 11:23 pm
  11134.   To: DENNIS DODSON (Rcvd)                                  (Read 79 times)
  11135. Subj: R: STRING MANIPULATION HELP
  11136.  
  11137. #include <stdio.h>        /* THIS IS TURBO-C BUT IS SAME FOR MS & QC */
  11138.  
  11139. /*Assuming you already have the string to be parsed in a char string
  11140. array:*/
  11141.  
  11142.  
  11143. main( void )
  11144. {
  11145.  
  11146.           char original_string[30] = "DENNIS R. WOOD";
  11147.  
  11148. /*          You can parse the string with one function call like this:*/
  11149.  
  11150.  
  11151.           char fname[30];
  11152.           char mname[30];
  11153.           char lname[30];
  11154.  
  11155.           sscanf( original_string, "%s%s%s", fname, mname, lname );
  11156.  
  11157.           /*then you can concatenate the first string with a 'space' and
  11158.           then the middle initial like this */
  11159.  
  11160.           strcat( fname, " ");
  11161.           strcat( fname, mname );
  11162.  
  11163.           /* fname now contains "DENNIS R." and lname contains "WOOD" */
  11164.  
  11165.  
  11166. }
  11167. ---------------
  11168. ** Current thread: STRING MANIPULATION HELP
  11169.  
  11170. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33MF2186 Date: 03/18/90
  11171. From: OTTO PORTER                                           Time: 11:36 am
  11172.   To: DENNIS DODSON (Rcvd)                                  (Read 81 times)
  11173. Subj: R: STRING MANIPULATION HELP
  11174.  
  11175. In looking at your question again I see that I didn't deal with the
  11176. case where you don't have a middle initial in the string.
  11177.  
  11178. In that case you could do the following:
  11179.  
  11180.     if( sscanf( original_string, "%s%s%s", fname, mname, lname) == 3 )
  11181.     {
  11182.         strcat(fname, " " );
  11183.         strcat(fname, mname);
  11184.     }
  11185.     else
  11186.        sscanf( original_string, "%s%s", fname, lname );
  11187.  
  11188. Anyway there are lots of ways to skin a cat.  You will get the idea.
  11189. ---------------
  11190. ** Current thread: STRING MANIPULATION HELP
  11191.  
  11192. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33NN1791 Date: 03/19/90
  11193. From: DENNIS DODSON                                         Time: 07:29 pm
  11194.   To: OTTO PORTER (Rcvd)                                    (Read 76 times)
  11195. Subj: STRING MANIPULATION HELP
  11196.  
  11197. Message CC'd to:
  11198.      OTTO PORTER
  11199.      GRANT ELLSWORTH
  11200.  
  11201. Hold on Guys,  I think I'm on to something.  Right now having problem
  11202. with a function overstepping null terminated string.  Hope to have a
  11203. routine for you to critique soon.  Sure is fun trying to learn all
  11204. over again!!! -Dennis-
  11205. ---------------
  11206. ** Current thread: STRING MANIPULATION HELP
  11207.  
  11208. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33PG1438 Date: 03/20/90
  11209. From: DENNIS DODSON                                         Time: 12:23 pm
  11210.   To: OTTO PORTER (Rcvd)                                    (Read 76 times)
  11211. Subj: STRING MANIPULATION HELP
  11212.  
  11213. Well, here it is.  Have tested it in my application program and works
  11214. fine.  I guess there's more than one way to skin a cat.  If you have
  11215. time and care to comment please do.  Thanks for getting me started, I
  11216. did acquire a little more knowledge with your help.
  11217.  
  11218. #include <stdio.h>
  11219. #include <conio.h>
  11220.  
  11221. /*
  11222.  * Routine to Break Employee Name to Last and First Name for Printing on
  11223.  * Wisconsin Unemployment Compensation Form UC-7832
  11224. */
  11225. main()
  11226. {
  11227.      char name_string[26];
  11228.      char first_name[26];  /* only 14 print positions on form */
  11229.      char last_name[24];   /* only 15 print positions on form */
  11230.      char s1[26], s2[24], s3[22], s4[20], s5[18], s6[16];
  11231.      int str_cnt;
  11232.      int pos;
  11233.  
  11234.      first_name[0] = last_name[0] = '\0';
  11235.      s1[0] = s2[0] = s3[0] = s4[0] = s5[0] = s6[0] = '\0';
  11236.  
  11237.      /* Copy input structure employee name to null terminated string */
  11238.      /* fstrcpy(name_string, employeerec.name, 25); */
  11239.  
  11240.      /* TESTING ONLY: */
  11241.      printf("Enter Name String: ");
  11242.      gets(name_string);
  11243.  
  11244.      /* Remove any periods '.' or commas ',' */
  11245.  
  11246.      for( pos = 0; pos < strlen(name_string); pos++ )
  11247.      {
  11248.          if (name_string[pos] == '.' || name_string[pos] == ',')
  11249.                name_string[pos] = ' ';
  11250.      }
  11251.  
  11252.      /* Break string up to 6 sub-strings (ex: Sue Lynn W Mc Donald MD) */
  11253.  
  11254.      str_cnt = sscanf(name_string, "%s%s%s%s%s%s", s1, s2, s3, s4, s5,
  11255. s6);
  11256.      if (str_cnt == 0)
  11257.          return;
  11258.  
  11259.  
  11260.      /* Append the sub-strings back together into the FIRST_NAME
  11261.       and the LAST_NAME variables as follows:
  11262.  
  11263.      +---------------------------+--------------+---------------+
  11264.      |       CONDITIONS:         |  FIRST NAME  |  *LAST NAME   |
  11265.      |---------------------------|--------------|---------------|
  11266.      | If s2 is 1 char. assume:  |Dennis R      |Dodson Sr      |
  11267.      |                Then Use:  | s1    s2     | s3 thru s6    |
  11268.      |---------------------------|--------------|---------------|
  11269.      | If s3 is 1 char. assume:  |Sue Lynn W    |Mc Donald MD   |
  11270.      |                Then Use:  | s1  s2  s3   | s4 thru s6    |
  11271.      |---------------------------|--------------|---------------|
  11272.      | Else Take a Chance !!!!:  |Joe           |Smith DDS      |
  11273.      |                     Use:  | s1           | s2 thru s6    |
  11274.      +---------------------------+--------------+---------------+
  11275.      | *Names such as "O Conner" HAVE to be keyed as "O'Conner" |
  11276.      +----------------------------------------------------------+  */
  11277.  
  11278.      /* ALWAYS Move 's1' to First Name */
  11279.  
  11280.      strcat(first_name, s1);
  11281.      if (str_cnt == 1)
  11282.          return;
  11283.  
  11284.      /* Now Build First and Last Name Based on Above Table */
  11285.  
  11286.      if (strlen(s2) == 1)   /* |Dennis R   |Dodson Sr    | */
  11287.      {
  11288.           strcat(first_name, " ");
  11289.           strcat(first_name, s2);
  11290.  
  11291.           if (str_cnt > 2)
  11292.                strcat(last_name, s3);
  11293.  
  11294.           if (str_cnt > 3)
  11295.           {
  11296.                strcat(last_name, " ");
  11297.                strcat(last_name, s4);
  11298.           }
  11299.      }
  11300.      else
  11301.      if (strlen(s3) == 1)   /* |Sue Lynn W |Mc Donald MD | */
  11302.      {
  11303.           if (str_cnt > 1)
  11304.           {
  11305.                strcat(first_name, " ");
  11306.                strcat(first_name, s2);
  11307.           }
  11308.  
  11309.           if (str_cnt > 2)
  11310.           {
  11311.           strcat(first_name, " ");
  11312. N
  11313.  
  11314.  
  11315.  
  11316. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33PR2415 Date: 03/20/90
  11317. From: GRANT ELLSWORTH (Leader)                              Time: 10:40 pm
  11318.   To: DENNIS DODSON (Rcvd)                                  (Read 77 times)
  11319. Subj: R: STRING MANIPULATION HELP
  11320.  
  11321. Dennis, re-examine the problem for handling multi-word 1st AND surnames
  11322. --- especially spanish or french surnames.  Then, throw in the middle
  11323. initial/name for the final oucher.  What the algorithm must do is to
  11324. separate ALL the words of the name and then work entirely from last
  11325. to first.  Oh yes, try something to handle the "Jr. Sr. III" suffix
  11326. qualifiers.
  11327.  
  11328. Then see if the algorithm can successfully parse the following:
  11329.  
  11330.   La Verne M. St. James
  11331.   Henrico L. de la garcia sanchez, jr.
  11332.  
  11333. as well as the common name forms.
  11334.  
  11335. Good luck!   Grant
  11336. ---------------
  11337. ** Current thread: STRING MANIPULATION HELP
  11338.  
  11339. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33SC0532 Date: 03/23/90
  11340. From: VICTOR DURA                                           Time: 08:08 am
  11341.   To: DENNIS DODSON (Rcvd)                                  (Read 76 times)
  11342. Subj: R: STRING MANIPULATION HELP
  11343.  
  11344. It looks like the bottom part of your name parsing routine got cut off.
  11345. Would you mind uploading it, I'm interested in reviewing it. Thanks
  11346. Vic Dura
  11347. .
  11348. ---------------
  11349. ** Current thread: STRING MANIPULATION HELP
  11350.  
  11351. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33TE0165 Date: 03/24/90
  11352. From: DENNIS DODSON                                         Time: 10:02 am
  11353.   To: VICTOR DURA (Rcvd)                                    (Read 80 times)
  11354. Subj: R: STRING MANIPULATION HELP
  11355.  
  11356. No problem Vic.  But it'll have to be on Monday - Don't have the source
  11357. code at home.  -Dennis-
  11358. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  11359.  
  11360. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33MH1850 Date: 03/18/90
  11361. From: IDC EMAIL                                             Time: 01:30 pm
  11362.   To: ALL                                                   (Read 69 times)
  11363. Subj: ASCII ROUTINE WANTED
  11364.  
  11365.  
  11366. Good day-
  11367.  
  11368. Does anyone out there have a MS C (or adaptable) routine for reading in
  11369. a large ASCII quote comma delimited file into an array?
  11370.  
  11371. None of the books I have (including the MS C manual, which serves as a
  11372. wonderful bird cage liner, but an awful reference guide) offer an
  11373. example of how this operation is performed.
  11374.  
  11375. If anyone has any old routines lying around to do this, or has a book
  11376. which documents this, please leave e-mail (to IDC EMAIL).
  11377.  
  11378. Many thanks - be 'C'ing you!
  11379.  
  11380. Brett Remington (IDC EMAIL)
  11381. ---------------
  11382. Following thread
  11383.  
  11384. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33NC2595 Date: 03/19/90
  11385. From: IDC EMAIL                                             Time: 08:43 am
  11386.   To: ROBERT BALSOVER (Rcvd)                                (Read 61 times)
  11387. Subj: R: ASCII ROUTINE WANTED
  11388.  
  11389. Bob-
  11390.  
  11391. Unfortunately, the device I am dealing with is a 6250 bpi tape with 13,500
  11392. records, and 251 fields per record.  While I don't actually read and store
  11393. each element, I do a conditional search for particular records and copy
  11394. them to a different device for computations.
  11395.  
  11396. I am a new C programmer, and I/O is an area which I have had little need
  11397. to explore.  Just another example of necessity being the mother of
  11398. invention, or learn by doing!
  11399.  
  11400. Thankx, and regards-
  11401. Brett (IDC EMAIL)
  11402. ---------------
  11403. ** Current thread: ASCII ROUTINE WANTED
  11404.  
  11405. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33NP2115 Date: 03/19/90
  11406. From: ROBERT BALSOVER                                       Time: 08:35 pm
  11407.   To: IDC EMAIL (Rcvd)                                      (Read 78 times)
  11408. Subj: R: ASCII ROUTINE WANTED
  11409.  
  11410. Brett,
  11411. If you change the comma's to '\n''s you could use fgets() to read in lines
  11412. until eof.
  11413. Bob
  11414. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  11415.  
  11416. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33QE1059 Date: 03/21/90
  11417. From: JUD ARNDT                                             Time: 10:17 am
  11418.   To: ALL                                                   (Read 76 times)
  11419. Subj: MS QUICK C FOR SALE
  11420.  
  11421.    Have complete MS Quick C for sale, in like new condition. Asking $50.00
  11422. for the whole package, which is Version 1.0 and includes everything. Leave
  11423. private, and I will reply. Will deliver in Milwaukee area, or you pay
  11424. shipping.
  11425. Jud...
  11426. ---------------
  11427.  
  11428. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33RA2280 Date: 03/22/90
  11429. From: RA SMITH                                              Time: 06:38 am
  11430.   To: ALL                                                   (Read 76 times)
  11431. Subj: C USERS JOURNAL SOURCE
  11432.  
  11433. Is there a BBS that contains source from the CUJ magazine?
  11434. ---------------
  11435.  
  11436. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33SS1843 Date: 03/23/90
  11437. From: GRANT ELLSWORTH (Leader)                              Time: 11:30 pm
  11438.   To: ROBERT BALSOVER (Rcvd)                                (Read 83 times)
  11439. Subj: LARGE MODEL TC BUGS?!?!?
  11440.  
  11441. Bob, Could you please be specific about the bugs you are finding when
  11442. using TC Large Model?  I have recently used TC2.0 large model in a com-
  11443. plex text-editor with image presentation/position enhancements.  I had
  11444. NO compiler related bugs in the TC code.  Yet, when I used M$C, I found
  11445. several compiler generated "anomalies" ---- such as reversing source and
  11446. target in a long sequence of strcpy/strcat calls.  And those were the
  11447. least of my "discoveries".  Grant
  11448. ---------------
  11449. Following thread
  11450.  
  11451. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33TE3372 Date: 03/24/90
  11452. From: ROBERT BALSOVER                                       Time: 10:56 am
  11453.   To: GRANT ELLSWORTH (Rcvd)                                (Read 85 times)
  11454. Subj: R: LARGE MODEL TC BUGS?!?!?
  11455.  
  11456. Grant,
  11457. The bugs don't belong to TC, they belong to the library Joe Campbell
  11458. wrote.  He must have not tested it in a large model.  The one problem that
  11459. comes to mind is a problem with the way he addressed the ports.  He used
  11460. that outb() macro, It's been a year since I fussed over it but it had
  11461. something to do with the parms in the macro being model specific.  I have
  11462. to admit that it might not be the way Joe wrote it, but maybe it depends
  11463. on a M$C quirk.  I think M$ has the quirk market cornered.
  11464. I don't use MSC so I haven't tried it with MSC.
  11465. Bob
  11466. ---------------
  11467. ** Current thread: LARGE MODEL TC BUGS?!?!?
  11468.  
  11469. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33TG2320 Date: 03/24/90
  11470. From: GRANT ELLSWORTH (Leader)                              Time: 12:38 pm
  11471.   To: ROBERT BALSOVER (Rcvd)                                (Read 86 times)
  11472. Subj: R: LARGE MODEL TC BUGS?!?!?
  11473.  
  11474. Bob, thanks for the clarification.  I interpretted your previous comments
  11475. to mean that you found bugs in the TC2.x large model generated code or
  11476. libraries.  If you had, that would be most unsettling.
  11477.  
  11478. As to quirks,  M$C sure can send you on very wild goose chases when you
  11479. are hunting for the reason your program crash.  That is verry time
  11480. consuming.   grant
  11481. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  11482.  
  11483. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33TL0308 Date: 03/24/90
  11484. From: PHIL KATZ                                             Time: 05:05 pm
  11485.   To: ALL                                                   (Read 84 times)
  11486. Subj: AMIGA PROGRAMMER WANTED
  11487.  
  11488.  
  11489. PKWARE has an immediate opening for a temporary full or part time position
  11490. for an Amiga programmer in the Milwaukee area.  Experience with 'C'
  11491. language on the Amiga is required.  Knowledge of 68000 assembly language
  11492. is also prefered, but not necessary.  Call 352-3670 during business hours
  11493. and ask for Hilde to schedule an interview, or send resume to PKWARE Inc.,
  11494. 7545 N. Port Washington Rd., Glendale, WI 53217.
  11495. ---------------
  11496.  
  11497. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33UQ3492 Date: 03/25/90
  11498. From: JIM MONROE                                            Time: 09:58 pm
  11499.   To: ALL                                                   (Read 76 times)
  11500. Subj: FINANCIAL CALCULATIONS
  11501.  
  11502. I am looking for some C source code for a financial calculator. Specific
  11503. functions are to calculate rate of return for variable payments.  Any held
  11504. is greatly appreciated.
  11505. ---------------
  11506.  
  11507. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33WH0075 Date: 03/27/90
  11508. From: STEVEN KRUEGER                                        Time: 01:01 pm
  11509.   To: ALL                                                   (Read 82 times)
  11510. Subj: TSR KEYS
  11511.  
  11512. Does anyone have a list of popular tsr programs and the keys used to
  11513. activate them, i am trying to write a tsr program that cannot interfere
  11514. with any of the other tsr programs. steve
  11515. ---------------
  11516.  
  11517. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33ZS1902 Date: 03/30/90
  11518. From: JIM NICKEL                                            Time: 11:31 pm
  11519.   To: ALL                                                   (Read 81 times)
  11520. Subj: ANYBODY HAVING PROBS W/ MAGNA CARTA?
  11521.  
  11522. The company I work for bought a copy of Magna Carta C Windowing package
  11523. for a project I'm doing on a PC.  I have been having trouble with this
  11524. package in that it seems incompatible with Turbo C.  I am writing what
  11525. might be considered a specialized word processor.  As such, most of the
  11526. data storage is done in RAM as a doubly-linked list.  It seems when I have
  11527. more than 5 windows on the screen at the same time, the Turbo C's free()
  11528. function does not release any memory.  More specifically, when i follow
  11529. the free() with xx=coreleft(), and examine xx, it doesn't change!
  11530. If I keep everything the same, but skip the display of one of the six
  11531. windows, the free() appears to work normally.  Is there a newer version
  11532. around that fixes this problem?  I am using version 2.07 of the package.
  11533. HELP!
  11534. Jim
  11535. ---------------
  11536. Following thread
  11537.  
  11538. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33^11696 Date: 03/31/90
  11539. From: JIM MONROE                                            Time: 12:28 am
  11540.   To: JIM NICKEL (Rcvd)                                     (Read 77 times)
  11541. Subj: R: ANYBODY HAVING PROBS W/ MAGNA CARTA?
  11542.  
  11543. I have been using this window package and a mix complier with no problem
  11544. (so far) .
  11545. ---------------
  11546. ** Current thread: ANYBODY HAVING PROBS W/ MAGNA CARTA?
  11547.  
  11548. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33^G0888 Date: 03/31/90
  11549. From: JEFF NOWLAND                                          Time: 12:14 pm
  11550.   To: JIM NICKEL (Rcvd)                                     (Read 75 times)
  11551. Subj: R: ANYBODY HAVING PROBS W/ MAGNA CARTA?
  11552.  
  11553. Jim,
  11554. I don't know the internals of the Magna Carta package, however, if the
  11555. coreleft routine does not report memory returned after the free statement,
  11556. it doesn't necessarily mean the memory wasn't freed.  It means that the
  11557. highest block of allocated memory has not been freed.  If Magna carta uses
  11558. some type of window array that grows in blocks of 5 window pointers or
  11559. some such thing, then the sixth window displayed would reaalloc the array
  11560. and move it to the top of the list of allocated blocks.  This would leave
  11561. a hole of free memory where the original array was, but coreleft would no
  11562. know about it.
  11563. JDNowland.
  11564. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  11565.  
  11566. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33^12608 Date: 03/31/90
  11567. From: JIM MONROE                                            Time: 12:43 am
  11568.   To: ALL                                                   (Read 74 times)
  11569. Subj: LOAN PAYMENTS
  11570.  
  11571. While there are many loan calculation programs, I have not found one with
  11572. C source code, any help would be appreciated?
  11573. ---------------
  11574.  
  11575. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 33^P1610 Date: 03/31/90
  11576. From: JIM NICKEL                                            Time: 08:26 pm
  11577.   To: ALL                                                   (Read 82 times)
  11578. Subj: FAR HEAP HELP WITH TURBO C NEEDED
  11579.  
  11580. I may have pointed the finger at Magna Carta incorrectly.
  11581. I have decided that part of my problem is that I was running out of memory
  11582. when I was allocating memory (medium model).  The Magna Carta windowing
  11583. package used the same heap (near heap) that my program was using for
  11584. dynamic allocation of RAM.  I decided that all of my problems would end
  11585. if I used the FAR heap for my data while the windowing package uses the
  11586. near heap.  I wanted to see how much free memory existed on the far heap
  11587. prior to starting my program, I put the following lines of code:
  11588.  
  11589. void main(void)
  11590. {
  11591.    printf("\nFar core left: %lu",farcoreleft());
  11592.    oldstruct=farmalloc(100));  /* Set starting address */
  11593.    printf("\nFar core left: %lu",farcoreleft());
  11594.    .
  11595.    .
  11596.    .
  11597. }
  11598.  
  11599. My program kept printing out 'Far core left: 0'.  Does this mean that
  11600. there
  11601. is NO memory available for the far heap?  I started to do some playing
  11602. around, and have a clue as to what's going on.  My Turbo C PRJ file
  11603. consists of about 20 seperate (source code modules) plus the medium
  11604. model of the Magna Carta library file.
  11605.  
  11606. It seems that if I remove about a dozen files from my project file, I can
  11607. get a non-zero number to appear for the Far core free space.  If I remove
  11608. yet another file, the number creeps a couple hundred bytes higher.
  11609. WHAT THE H___ is going on?  I thought that at nearly all (if not all)
  11610. of the far heap would be available since the code is stored in the CS
  11611. segment, right?  How can I find a spot in memory in which to do my thing?
  11612.  
  11613. I'm kinda burned out now, so I think I'll get away from this keyboard
  11614. and watch the Bucks game.
  11615.  
  11616. Jim
  11617. ---------------
  11618. Following thread
  11619.  
  11620. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 341H2408 Date: 04/01/90
  11621. From: NESHAM SOFTWARE                                       Time: 01:40 pm
  11622.   To: JIM NICKEL (Rcvd)                                     (Read 77 times)
  11623. Subj: R: FAR HEAP HELP WITH TURBO C NEEDED
  11624.  
  11625.   I have bumped into the same problem using the Microsoft compiler
  11626. at work. MSC has a function (I don't have the manual in front of me
  11627. because I use TC at home) that will try to allocate the memory from the
  11628. far heap and, failing that, try to allocate from the near heap. I think
  11629. the function is fmalloc(?). I have looked in the Turbo C Bible for the
  11630. equivalent but I don't see it. Perhaps you could call farmalloc() and if
  11631. that failed then malloc().
  11632. Some other problems that occur in DOS
  11633.    are due to the way memory is freed. If not freed correctly DOS may
  11634. not see it even if it is freed. This is called fragmented memory. I
  11635. just bring it up in case you haven't heard of it.
  11636.  
  11637.  Good luck.
  11638.                   Tim
  11639. ---------------
  11640. ** Current thread: FAR HEAP HELP WITH TURBO C NEEDED
  11641.  
  11642. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 341J2859 Date: 04/01/90
  11643. From: JIM NICKEL                                            Time: 03:47 pm
  11644.   To: NESHAM SOFTWARE (Rcvd)                                (Read 77 times)
  11645. Subj: R: FAR HEAP HELP WITH TURBO C NEEDED
  11646.  
  11647. I plan on calling Borland tomorrow to see what they say about it.
  11648. The thing that bothers me is that the far heap is supposed to be totally
  11649. independant from the near heap as far as I can see.  My boss is ordering a
  11650. package from somewhere that tries to allocate memory from the near heap,
  11651. and if that fails, from the far heap, and if that fails, from the disk.
  11652. Maybe there is some option there that may work.
  11653. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  11654.  
  11655. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 341J3004 Date: 04/01/90
  11656. From: JIM NICKEL                                            Time: 03:50 pm
  11657.   To: ALL                                                   (Read 79 times)
  11658. Subj: ALLOCATING TO DISK INSTEAD OF RAM
  11659.  
  11660. Anybody out there know of any kind of software package available that will
  11661. allow a c program to allocate chunks of memory from disk instead of RAM?
  11662. What I am looking for is something that works just like malloc() does in
  11663. C.
  11664. Jim
  11665. ---------------
  11666. Following thread
  11667.  
  11668. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 343R1466 Date: 04/03/90
  11669. From: JIM MONROE                                            Time: 10:24 pm
  11670.   To: JIM NICKEL (Rcvd)                                     (Read 77 times)
  11671. Subj: R: ALLOCATING TO DISK INSTEAD OF RAM
  11672.  
  11673. I have a similiar interest. If you get any replies please coarbon copy me
  11674. if possible.
  11675. Thanks
  11676. JIm Monroe
  11677. ---------------
  11678. ** Current thread: ALLOCATING TO DISK INSTEAD OF RAM
  11679.  
  11680. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 344R3327 Date: 04/04/90
  11681. From: JIM NICKEL                                            Time: 10:55 pm
  11682.   To: JIM MONROE (Rcvd)                                     (Read 79 times)
  11683. Subj: R: ALLOCATING TO DISK INSTEAD OF RAM
  11684.  
  11685. My boss called Borland up a week or so ago and they mentioned some program
  11686. that did that.  We should be getting a copy of it in a little while.  I
  11687. have absolutely no idea of what its capabilities are, so I can't offer a
  11688. comment on it. I was just wondering if anybody else on the conference had
  11689. success with any other program.  Squawk at you later...
  11690. Jim
  11691. ---------------
  11692. ** Current thread: ALLOCATING TO DISK INSTEAD OF RAM
  11693.  
  11694. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 345D1556 Date: 04/05/90
  11695. From: ROBERT BALSOVER                                       Time: 09:25 am
  11696.   To: JIM NICKEL (Rcvd)                                     (Read 79 times)
  11697. Subj: R: ALLOCATING TO DISK INSTEAD OF RAM
  11698.  
  11699. Jim && Jim,
  11700. Borland has a Vroom package in their Paradox program, it supposed to make
  11701. it into their language products sooner or later but its not there now.
  11702. Have you guys looked into a Dos Extender?  OS/386 has virtual memory
  11703. abilities (Eclipse Computer Solutions(i think)) and PharLap's product does
  11704. also.  If your machine has enough CPU muscle, you could use those.
  11705. OS/286 is available in two flavors, TC only and everyone's compiler.  The
  11706. TC only version is only $195 in the Programmers Connection mail order
  11707. catalog.  If you are considering that one, I called Eclipse yesterday and
  11708. virtual memory is not active in OS/286 even though the ad says it is.
  11709. Still, your program code would only occupy 50k of the normal memory while
  11710. the rest would operate in protected mode.
  11711. .
  11712. I hope this information is what your looking for.
  11713. Bob
  11714. ---------------
  11715. ** Current thread: ALLOCATING TO DISK INSTEAD OF RAM
  11716.  
  11717. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 345N0156 Date: 04/05/90
  11718. From: JIM MONROE                                            Time: 07:02 pm
  11719.   To: JIM NICKEL (Rcvd)                                     (Read 78 times)
  11720. Subj: R: ALLOCATING TO DISK INSTEAD OF RAM
  11721.  
  11722. I have down loaded a file called switch1.zip but have not tried it yet. If
  11723. I have any success I will pass the information along. See you later, Jim
  11724. Monroe
  11725. ---------------
  11726. ** Current thread: ALLOCATING TO DISK INSTEAD OF RAM
  11727.  
  11728. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 345R0374 Date: 04/05/90
  11729. From: JIM NICKEL                                            Time: 10:06 pm
  11730.   To: JIM MONROE (Rcvd)                                     (Read 79 times)
  11731. Subj: R: ALLOCATING TO DISK INSTEAD OF RAM
  11732.  
  11733. Wow, Jim.  I thought my need for an malloc to disk was so unusual, that I
  11734. completely forgot to check the Mahoney selection.  I'm glad somebody is
  11735. thinking out there.
  11736. Jim
  11737. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  11738.  
  11739. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 343C1373 Date: 04/03/90
  11740. From: SCOTT SIMONSON                                        Time: 08:22 am
  11741.   To: ALL                                                   (Read 74 times)
  11742. Subj: DISK-ID
  11743.  
  11744. HELLO, I USUALLY PROGRAM IN QUICK C AND AM CURRENTLY WORKING ON A VERY
  11745. SIMPLE PROGRAM TO DISPLAY AN "ID" OF WHO A CERTAIN DISK BELONGS TO.
  11746. MEANING, WHEN I ENTER "ID" IT SIMPLY DISPLAYS MY NAME AND ADDRESS INFO.
  11747.      MY QUESTION IS HOW DO I MAKE IT DISPLAYED EVERYTIME A "DIR" IS USED
  11748. ON THAT DISK, IF AT ALL POSSIBLE? I WAS THINKING MAYBE IT HAD SOMETHING TO
  11749. DO WITH THE FAT OF THAT DISK, SOME KIND OF ALTERING TO FORCE A DISPLAYED
  11750. MESSAGE. OH YES, IT CAN'T BE A TSR PROGRAM BECAUSE I WANT IT TO DISPLAY
  11751. WITHOUT ACTUALLY EXECUTING THE PROGRAM.
  11752.      IF THERE ARE ANY IDEAS OUT THERE IT WOULD MUCH APPRECIATED, ANY
  11753. COMMENTS TOO.
  11754.           THANKS FOR YOUR TIME!!!!!!
  11755.                                                   SCOTT SIMONSON
  11756. ---------------
  11757. Following thread
  11758.  
  11759. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 344K1498 Date: 04/04/90
  11760. From: COREY CLINGO                                          Time: 04:24 pm
  11761.   To: SCOTT SIMONSON (Rcvd)                                 (Read 76 times)
  11762. Subj: R: DISK-ID
  11763.  
  11764. Well, not making it a TSR makes it tougher.  You'd have to patch DOS to
  11765. change the DIR command to DI or something, then name your program DIR.
  11766. Alternatively, you could use something like 4DOS which allows you to
  11767. reassign internal commands.\
  11768.  
  11769. Corey
  11770. ---------------
  11771. ** Current thread: DISK-ID
  11772.  
  11773. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34AG2627 Date: 04/06/90
  11774. From: SCOTT SIMONSON                                        Time: 12:43 pm
  11775.   To: COREY CLINGO (Rcvd)                                   (Read 78 times)
  11776. Subj: R: DISK-ID
  11777.  
  11778. THANKS FOR THE REPLY COREY, BUT WHAT I WANT TO DO IS ALTER A DISK. MAKE IT
  11779. PORTABLE SO THAT ANYONE THAT DOES A "DIR" THE DISK-ID PROGRAM IS
  11780. DISPLAYED ON THAT DISK. I AM NOT SURE THAT THIS IS POSSIBLE BUT I'M TRYING
  11781. TO SEE IF IT IS. I'D THINK THAT IT HAVE SOMETHING TO DO WITH THE FAT OF
  11782. THE SAID DISK. AS FAR AS 4DOS, I'M ASSUMMING YOUR REFERRING TO DOS V.4.0.
  11783. IF DOS V.4.0 IS WHAT I NEED THAN I'LL KEEP TRYING TO FIND OTHER WAYS. IF
  11784. YOU HAVE ANY FURTHER COMMENTS, I WELCOME THEM, PLEASE!
  11785.                                    SCOTT SIMONSON
  11786. ---------------
  11787. ** Current thread: DISK-ID
  11788.  
  11789. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34AS2640 Date: 04/06/90
  11790. From: COREY CLINGO                                          Time: 11:44 pm
  11791.   To: SCOTT SIMONSON (Rcvd)                                 (Read 78 times)
  11792. Subj: R: DISK-ID
  11793.  
  11794. I don't know if there's enough space in the FAT for the kind of info you
  11795. want.  I kinda don't think there is.  Anyway, about 4DOS: it's a
  11796. substitute for COMMAND.COM with many additional features.  It's shareware
  11797. and on this BBS.  I'm still in my 30-day evaluation period, but I think I
  11798. will register it.  It looks like good stuff...
  11799.  
  11800. Corey
  11801. ---------------
  11802. ** Current thread: DISK-ID
  11803.  
  11804. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34TG0387 Date: 04/24/90
  11805. From: SCOTT SIMONSON                                        Time: 12:06 pm
  11806.   To: COREY CLINGO (Rcvd)                                   (Read 72 times)
  11807. Subj: R: DISK-ID
  11808.  
  11809. THANKS COREY!
  11810.                               SCOTT SIMONSON
  11811. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  11812.  
  11813. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34AQ2954 Date: 04/06/90
  11814. From: RICHARD WAMSER                                        Time: 09:49 pm
  11815.   To: ALL                                                   (Read 80 times)
  11816. Subj: HARDWARE INTERRUPTS
  11817.  
  11818. I HAVE A IBM AT COMPATABLE COMPUTER THAT I AM PROGRAMMING IN C ( JUST
  11819. LEARING ) -- MIRCOSOFT C V5.1 I AM TRYING TO PRINT A MESSAGE ON THE SCREEN
  11820. EVERYTIME I TAKE THE I/O BUSS INTERRUPT IRQ10 ( PIN # D3 ) HIGH IT APPEARS
  11821. THAT I CAN THRU THE MSC COMMAND    _dos_setvect   I CAN SET IN NEW VECTORS
  11822. BUT I AM NOT SURE IN ANY CASE WHEN EVER I TAKE IRQ10 HIGH ( GENERATE A
  11823. INTERRUPT ) I GET NO INDICATION  THAT AN INTERRUPT HAS OCCURED  I SURE
  11824. WOULD APPRECIATE ANY HELP OR ADVICE ANY ONE COULD GIVE ME ON WRITING A C
  11825. PROGRAM INTERRUPT HANDLER TO PRINT A MESSAGE ON THE SCREEN WHEN A IRQ10
  11826. INTERRUPT IS GENERATED
  11827.                                           THANKS FOR YOUR HELP & ADVICE
  11828.                                                          RICHARD
  11829. ---------------
  11830. Following thread
  11831.  
  11832. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34AQ3307 Date: 04/06/90
  11833. From: ROBERT BALSOVER                                       Time: 09:55 pm
  11834.   To: RICHARD WAMSER (Rcvd)                                 (Read 84 times)
  11835. Subj: R: HARDWARE INTERRUPTS
  11836.  
  11837. Richard,
  11838. If your just experimenting, try poking values to the right top corner of
  11839. the screen.  You might have better luck if you increment what is already
  11840. there, printing to the screen would be to slow for a interrupt.
  11841. Bob
  11842. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  11843.  
  11844. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34AR2296 Date: 04/06/90
  11845. From: JIM MONROE                                            Time: 10:38 pm
  11846.   To: ALL                                                   (Read 82 times)
  11847. Subj: SLOW CALCULATION
  11848.  
  11849. I have written the following program to calculate the fact that will give
  11850. the present value of a stream of payments. It is quite slow though, any
  11851. ideas to help speed it up would be appreciated;
  11852. double cal_fac(int term)
  11853. {
  11854.   double denon, factor = 0.;
  11855.   double mo_rate;
  11856.   mo_rate = rate/12;
  11857.   for ( i = 1; i <= term; i==)
  11858.    {
  11859.    factor += (i/(exp(i * (log(1+mo_rate)))));
  11860.    }
  11861. return(factor);
  11862. }
  11863. The variable rate is set up in the main routine, i, j , and k are int.
  11864. Any ideas will be appreciated.
  11865. Jim Monroe
  11866. ---------------
  11867. Following thread
  11868.  
  11869. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34AS3160 Date: 04/06/90
  11870. From: COREY CLINGO                                          Time: 11:52 pm
  11871.   To: JIM MONROE (Rcvd)                                     (Read 76 times)
  11872. Subj: R: SLOW CALCULATION
  11873.  
  11874. Well, I ran this code under Turbo C 2.0 and it was plenty fast, but I have
  11875. a coprocessor, which greatly speeds up transcendentals.  I'm kinda new to
  11876. C, but one thing that might help is to realize the fact that
  11877.    exp(i * log(...)) = (exp(i))^log(...)
  11878. You might be able to have a lookup table of the values of exp(i) for the
  11879. time periods you're interested in, and save yourself an exp() operation.
  11880.  
  11881. Corey
  11882. ---------------
  11883. ** Current thread: SLOW CALCULATION
  11884.  
  11885. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34BC1104 Date: 04/07/90
  11886. From: NESHAM SOFTWARE                                       Time: 08:18 am
  11887.   To: JIM MONROE (Rcvd)                                     (Read 75 times)
  11888. Subj: R: SLOW CALCULATION
  11889.  
  11890.    You could try using the register for loop counters.
  11891.    register int i;
  11892.    will use the register. TC may be defaulting to this if you are using
  11893. TC. The environment allows you to specify to use the register. MSC -
  11894. probably needs the above definition.
  11895.  
  11896.   Tim
  11897. ---------------
  11898. ** Current thread: SLOW CALCULATION
  11899.  
  11900. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34C23104 Date: 04/08/90
  11901. From: PAUL MCKENZIE                                         Time: 02:51 am
  11902.   To: JIM MONROE (Rcvd)                                     (Read 74 times)
  11903. Subj: R: SLOW CALCULATION
  11904.  
  11905. Jim,
  11906.      Take the log() outside of the loop.  The argument to log is a
  11907. constant.  For example:
  11908.       double x = log(1+mo_rate);
  11909.       for (i..)
  11910.         factor = exp(i*x);
  11911.    Hope this helps.
  11912. ---------------
  11913. ** Current thread: SLOW CALCULATION
  11914.  
  11915. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34C23475 Date: 04/08/90
  11916. From: PAUL MCKENZIE                                         Time: 02:57 am
  11917.   To: JIM MONROE (Rcvd)                                     (Read 75 times)
  11918. Subj: R: SLOW CALCULATION
  11919.  
  11920. Oops,
  11921.      factor += (i/(exp(i*x)));
  11922.    where x = log(1+mo_rate)
  11923.         Paul McKenzie
  11924. ---------------
  11925. ** Current thread: SLOW CALCULATION
  11926.  
  11927. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34FQ3525 Date: 04/11/90
  11928. From: JIM MONROE                                            Time: 09:58 pm
  11929.   To: COREY CLINGO (Rcvd)                                   (Read 70 times)
  11930. Subj: R: SLOW CALCULATION
  11931.  
  11932. will give it a try to see if it works any faster on my slow machine,
  11933. Thanks Jim Monroe
  11934. ---------------
  11935. ** Current thread: SLOW CALCULATION
  11936.  
  11937. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34FQ3585 Date: 04/11/90
  11938. From: JIM MONROE                                            Time: 09:59 pm
  11939.   To: NESHAM SOFTWARE (Rcvd)                                (Read 70 times)
  11940. Subj: R: SLOW CALCULATION
  11941.  
  11942. will give it a try, Thanks Jim Monroe
  11943. ---------------
  11944. ** Current thread: SLOW CALCULATION
  11945.  
  11946. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34FR0066 Date: 04/11/90
  11947. From: JIM MONROE                                            Time: 10:01 pm
  11948.   To: PAUL MCKENZIE (Rcvd)                                  (Read 68 times)
  11949. Subj: R: SLOW CALCULATION
  11950.  
  11951. Will give it a try, Thanks, Jim Monroe
  11952. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  11953.  
  11954. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34DP1813 Date: 04/09/90
  11955. From: DAVE CLAY                                             Time: 08:30 pm
  11956.   To: ALL                                                   (Read 75 times)
  11957. Subj: I DON'T "C" TOO GOOD.
  11958.  
  11959. A little help please.
  11960.     I am just learning C and could use a little help.  Does anyone
  11961. know of a assembly language function that can be called from MSC and
  11962. Turbo C which will allow me to read ALL regesters (except IP)?
  11963.     I am trying to use C instead of doing some long tasks in assembler.
  11964. As I enter an interrupt handler, I need to know AX, DX, SS, SP etc.
  11965. ,
  11966.     Of course, guess what, I also need a function which allows writing
  11967. ALL registers when I exit from an interrupt handler.  Any ideas????
  11968.                             Thanks,
  11969.                              Dave Clay
  11970. ---------------
  11971. Following thread
  11972.  
  11973. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34FM0303 Date: 04/11/90
  11974. From: NESHAM SOFTWARE                                       Time: 06:05 pm
  11975.   To: DAVE CLAY (Rcvd)                                      (Read 71 times)
  11976. Subj: R: I DON'T "C" TOO GOOD.
  11977.  
  11978.   Check out functions like int86 which allow you to specify the values
  11979. of the registers. On return you would access the members of the UNION
  11980. Regs  which allows access to the register return values from an interrupt
  11981. call. The union REGS is defined in the file dos.h which comes with TurboC
  11982. or MSC.
  11983.  
  11984.     Tim
  11985. ---------------
  11986. ** Current thread: I DON'T "C" TOO GOOD.
  11987.  
  11988. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34FP0226 Date: 04/11/90
  11989. From: DAVE CLAY                                             Time: 08:03 pm
  11990.   To: NESHAM SOFTWARE (Rcvd)                                (Read 71 times)
  11991. Subj: R: I DON'T "C" TOO GOOD.
  11992.  
  11993. Tim,
  11994. ■≥  Thanks √ f■≥or t √he  tip.  My trouble is that my interrupt gets
  11995. garbagenumbers because I have no way of keeping the uninitialized psudeo
  11996. register numbers from being dropped into the interrupt when the hardware
  11997. calls the interrupt √.  INT86 is great for calling an interrupt form C
  11998. but it is no good if the hardware is calling the interrupt.
  11999.                     Thanks
  12000.                     Dave Clay
  12001. ---------------
  12002. ** Current thread: I DON'T "C" TOO GOOD.
  12003.  
  12004. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34IJ1641 Date: 04/14/90
  12005. From: JEFF NOWLAND                                          Time: 03:27 pm
  12006.   To: DAVE CLAY (Rcvd)                                      (Read 69 times)
  12007. Subj: R: I DON'T "C" TOO GOOD.
  12008.  
  12009. Dave,
  12010. If you are using TC then declaring your interrupt handler as being
  12011. interrupt will automatically save and restore all registers for you. Also
  12012. if your function is written as:
  12013.   void interrupt handler( bp,di,si,ds,es,dx,cx,bx,ax);
  12014.   unsigned bp,di,si,ds,es,dx,cx,bx,ax;
  12015. then you have the registers you need as normal C parms.
  12016. JDNowland.
  12017. ---------------
  12018. ** Current thread: I DON'T "C" TOO GOOD.
  12019.  
  12020. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 353N2386 Date: 05/03/90
  12021. From: DAVE CLAY                                             Time: 07:39 pm
  12022.   To: JEFF NOWLAND (Rcvd)                                   (Read 73 times)
  12023. Subj: R: I DON'T "C" TOO GOOD.
  12024.  
  12025. Jeff,
  12026.          Thanks for the help.  I was using MSC but you gave a very good
  12027. reason for switching to Turbo C.
  12028.          Eventhough Turbo C saves the registers, can I get hold of them
  12029. without disturbing them?  In other words, can I read what they were
  12030. when the interrupt went off without affecting them?
  12031.          Thanks much,
  12032.          Dave Clay
  12033. ---------------
  12034. ** Current thread: I DON'T "C" TOO GOOD.
  12035.  
  12036. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 354Q1186 Date: 05/04/90
  12037. From: JEFF NOWLAND                                          Time: 09:19 pm
  12038.   To: DAVE CLAY                                             (Read 72 times)
  12039. Subj: R: I DON'T "C" TOO GOOD.
  12040.  
  12041. Dave,
  12042. Yes!
  12043. In the TurboC world, if you declare your interrupt function as:
  12044. void interrupt my_handler( unsigned bp, unsigned di, unsigned si, unsigned
  12045. ds, unsigned es, unsigned dx, unsigned cx, unsigned bx, unsigned ax ) then
  12046. you may view and/or modify the incoming registers as you wish.
  12047. JDNowland.
  12048. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  12049.  
  12050. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34GQ2153 Date: 04/12/90
  12051. From: T
  12052. Following thread
  12053.  
  12054. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34HN1525 Date: 04/13/90
  12055. From: ROBERT BALSOVER                                       Time: 07:25 pm
  12056.   To: JIM NICKEL (Rcvd)                                     (Read 72 times)
  12057. Subj: R: GLOBAL STRINGS IN TURBO C
  12058.  
  12059. Jim,
  12060. If you declared the buffer as a external buffer space won't be allocated
  12061. for it at compile time.  This would result in no errors when compiling but
  12062. when you link the linker *will* look for that buffer.  You get a error
  12063. message like the one you got in that case.  Just a guess but I can't see
  12064. the source to be sure.
  12065. Bob
  12066. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  12067.  
  12068. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34HE2219 Date: 04/13/90
  12069. From: RICHARD MILLER                                        Time: 10:37 am
  12070.   To: ALL                                                   (Read 70 times)
  12071. Subj: PASCAL TO C
  12072.  
  12073. I have a small program that I am trying to convert from Pascal to C.
  12074. i plan to use it as a procedure in clipper. It is Probably 60% converted
  12075. but I'am at a P\point that I need some help. I am willing to compesate you
  12076. for your time spent. Please leave me a message.
  12077.  
  12078.                                   Thanks
  12079.                                   Richard
  12080. ---------------
  12081. Following thread
  12082.  
  12083. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34HN1587 Date: 04/13/90
  12084. From: ROBERT BALSOVER                                       Time: 07:26 pm
  12085.   To: RICHARD MILLER (Rcvd)                                 (Read 72 times)
  12086. Subj: R: PASCAL TO C
  12087.  
  12088. Richard,
  12089. Hoe many lines are we talking about?
  12090. Bob
  12091. ---------------
  12092. ** Current thread: PASCAL TO C
  12093.  
  12094. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34IC2528 Date: 04/14/90
  12095. From: RICHARD MILLER                                        Time: 08:42 am
  12096.   To: ROBERT BALSOVER (Rcvd)                                (Read 73 times)
  12097. Subj: R: PASCAL TO C
  12098.  
  12099. Bob,
  12100.      Thanks for replying. There are approx. 200 lines, but I have already
  12101. converted Probably 50% or more to Turbo C. The remainder are more involved
  12102. than by basic knowledge of C. I hope you can help.
  12103. Richard
  12104. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  12105.  
  12106. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34HE3231 Date: 04/13/90
  12107. From: DENNIS DODSON                                         Time: 10:53 am
  12108.   To: ALL                                                   (Read 69 times)
  12109. Subj: .BAT FROM C .EXE
  12110.  
  12111. Is it possible to leave a C program and start-up a batch (.bat) job ?
  12112. I've tried the 'exec' family with unsuccessfull results, program seems
  12113. to hang.  Any suggestions would be appreciated.   -Dennis-
  12114. ---------------
  12115. Following thread
  12116.  
  12117. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34HN2006 Date: 04/13/90
  12118. From: ROBERT BALSOVER                                       Time: 07:33 pm
  12119.   To: DENNIS DODSON (Rcvd)                                  (Read 70 times)
  12120. Subj: R: .BAT FROM C .EXE
  12121.  
  12122. Dennis,
  12123. You have to call coomand.com with the batch file name as a parmeter.
  12124. ie. execl("COMMAND.COM","BTCHFILE.BAT",NULL);
  12125. .
  12126. What I think you want to do is call spawn instead. ie.
  12127. spawnl("C:\\COMMAND.COM","BTCHFILE.BAT",NULL);
  12128. .
  12129. The exec...() family of functions overlays the current program in memory.
  12130. That means that once command.com finish processing and returned, the is
  12131. nothing to return to.  spawn...() functions don't overlay themselfs.
  12132. .
  12133. Bob
  12134. ---------------
  12135. ** Current thread: .BAT FROM C .EXE
  12136.  
  12137. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34IF1168 Date: 04/14/90
  12138. From: DENNIS DODSON                                         Time: 11:19 am
  12139.   To: ROBERT BALSOVER (Rcvd)                                (Read 71 times)
  12140. Subj: R: .BAT FROM C .EXE
  12141.  
  12142. Thanks Bob, that's exactly what I wanted to know.  Yes I do wnat to run
  12143. the 'exec' type function.  The daily batch run should be executed from
  12144. an on-line program, flushed out, etc. and when the lengthly batch run
  12145. is done, will return the operator to the main menu for further action.
  12146. Thanks again Bob for the hint.
  12147. -Dennis-
  12148. ---------------
  12149. ** Current thread: .BAT FROM C .EXE
  12150.  
  12151. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34IL3301 Date: 04/14/90
  12152. From: ROBERT BALSOVER                                       Time: 05:55 pm
  12153.   To: DENNIS DODSON (Rcvd)                                  (Read 65 times)
  12154. Subj: R: .BAT FROM C .EXE
  12155.  
  12156. your welcome
  12157. Bob
  12158. ---------------
  12159. ** Current thread: .BAT FROM C .EXE
  12160.  
  12161. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34JH2600 Date: 04/15/90
  12162. From: JOE VINCENT                                           Time: 01:43 pm
  12163.   To: DENNIS DODSON (Rcvd)                                  (Read 69 times)
  12164. Subj: R: .BAT FROM C .EXE
  12165.  
  12166. Dennis, both the "spawn" and "exec" functions are meant to invoke
  12167. executable programs.  If you want to invoke a .BAT from within a C
  12168. program, why wouldn't "system" be the logical choice?  Am I missing
  12169. something?
  12170.  
  12171.      -=≡{JOE}≡=- (tm)
  12172. ---------------
  12173. ** Current thread: .BAT FROM C .EXE
  12174.  
  12175. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34JP3412 Date: 04/15/90
  12176. From: JIM MONROE                                            Time: 08:56 pm
  12177.   To: JOE VINCENT (Rcvd)                                    (Read 69 times)
  12178. Subj: R: .BAT FROM C .EXE
  12179.  
  12180. It seems that the biggest portion of this problem is the return. I think
  12181. that the use of a bat file will return to dos prompt, this may not be the
  12182. desired result.
  12183. ---------------
  12184. ** Current thread: .BAT FROM C .EXE
  12185.  
  12186. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34KM0041 Date: 04/16/90
  12187. From: JOE VINCENT                                           Time: 06:00 pm
  12188.   To: JIM MONROE (Rcvd)                                     (Read 73 times)
  12189. Subj: R: .BAT FROM C .EXE
  12190.  
  12191. >It seems that the biggest portion of this problem is the return. I think
  12192. >that the use of a bat file will return to dos prompt, this may not be the
  12193. >desired result.
  12194.  
  12195. I think I'll do some empirical research and find out.  If it doesn't work
  12196. directly, it seems as if you could use "system" to invoke a second copy of
  12197. command.com with a /c to execute the .BAT.  Right now, I don't see why a
  12198. "system" of the .BAT shouldn't work directly.  I'm really speculating
  12199. here.
  12200.  
  12201.      -=≡{JOE}≡=- (tm)
  12202. ---------------
  12203. ** Current thread: .BAT FROM C .EXE
  12204.  
  12205. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34KR1811 Date: 04/16/90
  12206. From: GRANT ELLSWORTH (Leader)                              Time: 10:30 pm
  12207.   To: JOE VINCENT (Rcvd)                                    (Read 70 times)
  12208. Subj: R: .BAT FROM C .EXE
  12209.  
  12210. Joe , I remember using the "system()" function some time back to address
  12211. a special problem --- there is a return code issued, but it's limited to
  12212. a 0 if opertion was successful and -1 when it is not (ie. the .bat file
  12213. did not exist of failed due to a command failure).  The best workaround
  12214. is clumsy, if sensing a specific errorlevel or exit code is desired ...
  12215. The .bat file must do something like the following:
  12216.   ...
  12217.   SET ENVVAR=%ERRORLEVEL%
  12218.   echo %ENVVAR% >return.cod
  12219.  
  12220. And then the pgm must read the file, return.cod, to get the actual exit
  12221. code.  Real ugly.
  12222.  
  12223. Grant
  12224. ---------------
  12225. ** Current thread: .BAT FROM C .EXE
  12226.  
  12227. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34LG3186 Date: 04/17/90
  12228. From: DENNIS DODSON                                         Time: 12:53 pm
  12229.   To: JOE VINCENT (Rcvd)                                    (Read 73 times)
  12230. Subj: R: .BAT FROM C .EXE
  12231.  
  12232. The purpose of my original '.bat from .exe' question was that I wanted to
  12233. initiate a daily batch run from a on-line type C program for an account-
  12234. ing system that I am redeveloping for my employer.  This system is being
  12235. rewritten from mainframe (Cobol, RPG, Assembly) to Novell Networked PC's.
  12236. Journal entries, payroll data, and file maintenance are performed daily
  12237. for a set of clients to be process that day.  The C program in question
  12238. is a 'run control' master maintenance type program where the clients to
  12239. be processed that day in the batch run are displayed to the supervisor
  12240. and he/she has the option of 'holding' or changing certain clients from
  12241. the batch run because of unknown circumstances that may warrant this
  12242. action.  One of the menu items in this program is to 'RUN' the daily
  12243. batch run.  I thought this would be better than having the operator
  12244. exit to DOS and having them type in a batch file name to execute.
  12245.  
  12246. An important requirement of this process is that the memory in the PC
  12247. will be at its maximum as some of the batch C programs are very large
  12248. and probably would not execute as a child of this calling program.
  12249.  
  12250. I have tried Bob B.'s suggestion of the EXECLP (retain path) and am having
  12251. trouble with command.com being found on the network, even though it is
  12252. in the Path and Comspec.  I have thought about trying the SPAWNLP function
  12253. with P_OVERLAY mode and will try next.  Batch run would execute, can check
  12254. errorlevel status, inform operator, etc., and would return to calling
  12255. program.  Operator would then exit to Main Menu.  I have had a problem
  12256. with memory errors the last two days and am awaiting replacement probably
  12257. tomorrow, cannot perform M$C 5.0 link, getting 110 errors and then hangs
  12258. processor, i.e., can compile, but not link program to test further.
  12259.  
  12260. Anyway, I just thought I should reinforce the reasons for my query as I
  12261. have seen more discussion on it.  Thanks for the response all of you.
  12262. The SYSTEM command probably would not be desireable as I assume there
  12263. would be a problem with insufficient memory.
  12264.  
  12265. -Dennis-
  12266. ---------------
  12267. ** Current thread: .BAT FROM C .EXE
  12268.  
  12269. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34LL2809 Date: 04/17/90
  12270. From: JOE VINCENT                                           Time: 05:46 pm
  12271.   To: GRANT ELLSWORTH (Rcvd)                                (Read 68 times)
  12272. Subj: R: .BAT FROM C .EXE
  12273.  
  12274. I wasn't paying attention.  I forgot the part about wanting to get back an
  12275. error code from the batch file execution.  "Spawn" is the only way I know
  12276. to do that in an elegant manner.  Good catch!
  12277.  
  12278.      -=≡{JOE}≡=- (tm)
  12279. ---------------
  12280. ** Current thread: .BAT FROM C .EXE
  12281.  
  12282. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34LL3020 Date: 04/17/90
  12283. From: JOE VINCENT                                           Time: 05:50 pm
  12284.   To: DENNIS DODSON (Rcvd)                                  (Read 68 times)
  12285. Subj: R: .BAT FROM C .EXE
  12286.  
  12287. Dennis, I've printed your explanation of your problem and will, as my
  12288. grandfather used to say, "study on it."  It's an interesting problem.  I
  12289. had missed the part about needing to get back an error code from the batch
  12290. file execution.  Let me ponder this.
  12291.  
  12292.      -=≡{JOE}≡=- (tm)
  12293. ---------------
  12294. ** Current thread: .BAT FROM C .EXE
  12295.  
  12296. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34LS1150 Date: 04/17/90
  12297. From: JIM MONROE                                            Time: 11:19 pm
  12298.   To: JOE VINCENT (Rcvd)                                    (Read 66 times)
  12299. Subj: R: .BAT FROM C .EXE
  12300.  
  12301. Good Luck, I have not tried this procedure but am interested in finding
  12302. out the results.
  12303. Jim Monroe
  12304. s
  12305. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  12306.  
  12307. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34II2665 Date: 04/14/90
  12308. From: RICHARD WAMSER                                        Time: 02:44 pm
  12309.   To: ALL                                                   (Read 70 times)
  12310. Subj: C PROGRAM INTERRUPT HANDLER
  12311.  
  12312. I would Appreciate any help or comments on writting a Hardware Interrupt
  12313. for a AT BUSS Comouter. In particular for I/O BUSS Hardware Interrupt
  12314. IRQ11 I have used the Mircosoft C v5.1 System Call  _dos_setvect  to set a
  12315. new set of VECTORS in to Handle a Hardware Interrupt ( IRQ11 ) the Vectors
  12316. seem to change after I have installed them but, I can't get any indication
  12317. that the Hardware Interrupt was serviced  I think that my problem is in
  12318. the Interrupt Handler Routine That I wrote but am sure is incorrect So I
  12319. sure would Appreciate any help I could get on writting a Hardware
  12320. Interrupt Handler Routine
  12321.                                           Thanks for Your Help
  12322.                                             Richard
  12323. ---------------
  12324. Following thread
  12325.  
  12326. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34IJ2221 Date: 04/14/90
  12327. From: JEFF NOWLAND                                          Time: 03:37 pm
  12328.   To: RICHARD WAMSER (Rcvd)                                 (Read 70 times)
  12329. Subj: R: C PROGRAM INTERRUPT HANDLER
  12330.  
  12331. Richard,
  12332. Make sure you are setting the correct set of vectors.  IRQ 11h is serviced
  12333. at VECTOR 73h.  Also, the interrupt controller must be given an
  12334. end-of-interrupt signal on both interrupt controllers(irq 11h is cascaded
  12335. from a second interrupt controller to irq 2)
  12336. JDNowland.
  12337. ---------------
  12338. ** Current thread: C PROGRAM INTERRUPT HANDLER
  12339.  
  12340. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34IQ1076 Date: 04/14/90
  12341. From: RICHARD WAMSER                                        Time: 09:17 pm
  12342.   To: JEFF NOWLAND (Rcvd)                                   (Read 71 times)
  12343. Subj: R: C PROGRAM INTERRUPT HANDLER
  12344.  
  12345. Jeff,
  12346. Thank You for your reply, most of what you said I understand but, I still
  12347. could use some help in implamenting what you said with what I have
  12348. written in a IRQ11 Interrupt Handler.  If you have some time and interest
  12349. I have UPLOADED 3 Files RWI.C  the source file for my Interrupt Handler it
  12350. was written in Mircosoft v5.1  RWI.OBJ  the object File for the source
  12351. code and  RWI.EXE  the excuteable File of the source File.  I would sure
  12352. appreciate any comments, corrections, or additions that you might make or
  12353. suggest.
  12354.                                          Thanks for Your Help:
  12355.                                          Richard
  12356. ---------------
  12357. ** Current thread: C PROGRAM INTERRUPT HANDLER
  12358.  
  12359. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34WM0400 Date: 04/27/90
  12360. From: JEFF NOWLAND                                          Time: 06:06 pm
  12361.   To: RICHARD WAMSER (Rcvd)                                 (Read 76 times)
  12362. Subj: R: C PROGRAM INTERRUPT HANDLER
  12363.  
  12364. Rich,
  12365. The reason your program didn't work was that you were not pointing farptr
  12366. to video memory(unless MC5.1 is much different than TC in storing
  12367. pointers).  Line 44 of RWI.C was farptr = ( int far * )0xb000864;
  12368. It should have been farptr = ( int far * )0xb0000864; The segment value is
  12369. the most significant 4hex digits and the offset is the least significant
  12370. 4hex digits, so B000:864 is stored as 0xB0000864.  If your interrupt
  12371. handler doesn't do anything to your system that would be harmful if
  12372. simulated you can test it by direct calling it.  It is probably getting
  12373. called correctly by the hardware, but it is writing INTERRUPT to location
  12374. B00:864 in memory instead of B000:864(redundant?)
  12375. Sorry it took so long to get back, hope this helps.
  12376. JDNowland.
  12377. ---------------
  12378. ** Current thread: C PROGRAM INTERRUPT HANDLER
  12379.  
  12380. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34WS0125 Date: 04/27/90
  12381. From: RICHARD WAMSER                                        Time: 11:02 pm
  12382.   To: JEFF NOWLAND (Rcvd)                                   (Read 70 times)
  12383. Subj: R: C PROGRAM INTERRUPT HANDLER
  12384.  
  12385. Jeff;
  12386. Thanks for the info on the far pointer into Video memory I have just read
  12387. your message and as soon as I get a chance I will change the source code
  12388. in my Interrupt program and try  and see if it will then work. Since your
  12389. only comment was on the far pointer into Video memory it would seem that
  12390. you think that the rest of the code might be OK. l after I try it I will
  12391. let you know if it works. Thanks again for you time, intrest, and
  12392. comments.  By the way do you know any thing about D M A  Direct Memory
  12393. Access ?  I have started to read up on this subject with the hope of some
  12394. day figuring out how to implament D M A on my computer  Any help you could
  12395. give me on this subject would be most appreciated both in  hardware &
  12396. software.  Thanks again
  12397. Rich
  12398. ---------------
  12399. ** Current thread: C PROGRAM INTERRUPT HANDLER
  12400.  
  12401. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34YI3481 Date: 04/29/90
  12402. From: JEFF NOWLAND                                          Time: 02:58 pm
  12403.   To: RICHARD WAMSER (Rcvd)                                 (Read 72 times)
  12404. Subj: R: C PROGRAM INTERRUPT HANDLER
  12405.  
  12406. Rich,
  12407. Glad to be of service. I didn't see anything else that was definitely
  12408. wrong with the code.  You may wish to debug the IRQ2 vector to make sure
  12409. that the following is happening:
  12410. 1) that the interrupt controllers are being reset by sending out an
  12411. eoi(20h) to ports 20h(for main controller) and A0h(cascaded controller)
  12412. 2) that interrupts are enabled after return from interrupt(so clock, etc.
  12413. continue to operate)
  12414. 3)depending on what the program is supposed to do and when the interrupt
  12415. occurs it may be wise to save the current stack as well as all registers,
  12416. then switch to your own stack.
  12417. Type again if have more Qs.
  12418. JDNowland.
  12419. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  12420.  
  12421. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34JQ0081 Date: 04/15/90
  12422. From: JIM MONROE                                            Time: 09:01 pm
  12423.   To: ALL                                                   (Read 69 times)
  12424. Subj: HOW TO USE HEADER FILES
  12425.  
  12426. Is there a good book, article or whatever explaining how to use an
  12427. individual's self created header files.  I seem to have no problem with
  12428. the idea of defining variables within these file but how do you actually
  12429. define a function and where is the function (header or some where else)
  12430. code?
  12431. ---------------
  12432. Following thread
  12433.  
  12434. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34KR1322 Date: 04/16/90
  12435. From: GRANT ELLSWORTH (Leader)                              Time: 10:22 pm
  12436.   To: JIM MONROE (Rcvd)                                     (Read 71 times)
  12437. Subj: R: HOW TO USE HEADER FILES
  12438.  
  12439. Jim, on header files ....
  12440.  
  12441. Typically, the header files are used to:
  12442.  
  12443. o define/declare symbols and structures
  12444. o establish function prototypes
  12445. o declare common "extern" references
  12446.  
  12447. You would use the header files to provide this common base of definitions
  12448. to a set of separately comipiled routines which must share these common
  12449. definitions
  12450.  
  12451. I very rarely use a header file to declare a true variable since this can
  12452. lead to a linker error : symbol xxx defined in .... (several separate
  12453. modules).  When absolutely necessary to declare a true variable in a
  12454. header file for common access, I will make the variable an extern and use
  12455. an #ifdef __MY_MAIN__  #define extern  (blank)   #endif construct to nul-
  12456. lify the "extern" in the main (or pre-chosen) module where I want the
  12457. variable declared to "exist" (its home, if you will).
  12458.  
  12459. The book "The C Programming" by Jack(?) Purdom published by Que, now in
  12460. its 2nd edition, contains some examples and illustrations of header file
  12461. usage.
  12462.  
  12463. Hope this gets you started ... Grant
  12464. ---------------
  12465. ** Current thread: HOW TO USE HEADER FILES
  12466.  
  12467. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34LS1232 Date: 04/17/90
  12468. From: JIM MONROE                                            Time: 11:20 pm
  12469.   To: GRANT ELLSWORTH (Rcvd)                                (Read 66 times)
  12470. Subj: R: HOW TO USE HEADER FILES
  12471.  
  12472. Will give it a try and also try to get the book. Thanks
  12473. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  12474.  
  12475. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34L40666 Date: 04/17/90
  12476. From: TED GAGLIANO                                          Time: 04:11 am
  12477.   To: ALL                                                   (Read 70 times)
  12478. Subj: PI
  12479.  
  12480. Hello out there. I am new to this conference and I would like your help.
  12481. Included in this message is a "C" program for calculating PI out to 10K
  12482. places. I tried it out and it works as advertized. What stumps me is HOW !
  12483. I have some background in "C" but can not follow this program flow. I can
  12484. see
  12485. that memory seems to be used to hold the numbers. What I would like help
  12486. on
  12487. is comments. Could one of you guys comment the dickens out of this code
  12488. and reload it back as a message. I need detailed commenting as if I knew
  12489. little or nothing. This way I can bypass what I do know and try to absorb
  12490. the new stuff. The real meat is how the actual calcultion is done without
  12491. loosing accuracy. If this one does 10,000 places, why not 20,000 or
  12492. 64,000 or for ever and ever until I run out of hard disk space ?? Thanks
  12493. in advance for any help. I am hoping this will be an intellectual
  12494. challenge
  12495. for the bored pro....<TRG>
  12496.  
  12497. Please be aware that because of the 99 line limit I have cut this
  12498. program into 4 pieces. Here is PART 1
  12499.  
  12500.  
  12501.  /*
  12502.   *  PI - program to print PI to N places
  12503.   *  1st argument is the number of places desired. Space is allocated
  12504.   *  by dynamic allocation.
  12505.   *
  12506.   *  Programmed by Bill Davidsen after the method of G. M. Roe,
  12507.   *  based on a version for "E" supplied with the "B" compiler, 1970
  12508.   *
  12509.   *  Modified by Alexander Morris, September 9, 1987 to be fully
  12510. compatible
  12511.   *  with Borland's Turbo C
  12512.   */
  12513.  
  12514. #include <stdio.h>
  12515. #include <alloc.h>
  12516.  
  12517. long  kf, ks, *mf, *ms;
  12518. long  cnt, n, i, temp, nd;
  12519. long  col, col1;
  12520. long  loc, stor[21];
  12521. ---------------
  12522.  
  12523. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34L40806 Date: 04/17/90
  12524. From: TED GAGLIANO                                          Time: 04:13 am
  12525.   To: ALL                                                   (Read 68 times)
  12526. Subj: PI-PART2
  12527.  
  12528. This is PART2++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  12529.  
  12530.  
  12531. main (argc, argv)
  12532.   int  argc;
  12533.   char *argv[];
  12534. {
  12535.     col = col1;
  12536.  
  12537.     stor[i++] = 0;                  /* also init */
  12538.  
  12539.     if (argc < 2) {
  12540.         fprintf (stderr, "Format is:\n\tpi <# places>\n");
  12541.         exit ();
  12542.     }
  12543.  
  12544.     n = atoi (argv[1]);                 /* get the digits requested */
  12545.     mf = calloc ((int)n+3, sizeof (long));
  12546.     ms = calloc ((int)n+3, sizeof (long));
  12547.     cnt = 0;
  12548.  
  12549.     kf = 25;
  12550.  
  12551.     ks = 57121L;
  12552.  
  12553.     mf[1] = 1;
  12554.     for (i = 2; i <= n; i += 2) {
  12555.  
  12556.         mf[i] = -16;
  12557.  
  12558.         mf[i + 1] = 16;
  12559.  
  12560.     }
  12561.  
  12562.     for (i = 1; i <= n; i += 2) {
  12563.         ms[i] = -4;
  12564.  
  12565.         ms[i + 1] = 4;
  12566.     }
  12567.  
  12568.  
  12569.  
  12570.  
  12571.     printf ("\n 3.");
  12572.  
  12573.     while (cnt < n) {
  12574.         for (i = 0; ++i <= n - cnt;) {
  12575.  
  12576.             mf[i] *= 10;
  12577.  
  12578.             ms[i] *= 10;
  12579.  
  12580.         }
  12581.  
  12582.         for (i = n - cnt + 1; --i >= 2;) {
  12583.             temp = 2 * i - 1;
  12584.  
  12585.             shift (&mf[i - 1], &mf[i], temp - 2, temp * kf);
  12586.  
  12587.             shift (&ms[i - 1], &ms[i], temp - 2, temp * ks);
  12588.         } nd = 0;
  12589.  
  12590.  
  12591.  
  12592.         shift (&nd, &mf[1], 1L, 5L);
  12593.  
  12594.         shift (&nd, &ms[1], 1L, 239L);
  12595.         xprint (nd);
  12596.  
  12597.     }
  12598.  
  12599. }
  12600.  
  12601.  
  12602.  
  12603. ---------------
  12604.  
  12605. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34L40900 Date: 04/17/90
  12606. From: TED GAGLIANO                                          Time: 04:15 am
  12607.   To: ALL                                                   (Read 67 times)
  12608. Subj: PI-PART3
  12609.  
  12610.  
  12611. Here is PART3+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  12612.  
  12613.  
  12614. shift (l1, l2, lp, lmod)
  12615. long *l1, *l2, lp, lmod;
  12616.  
  12617. {
  12618.  
  12619.     long  k;
  12620.  
  12621.  
  12622.     k = ((*l2) > 0 ? (*l2) / lmod : -(-(*l2) / lmod) - 1);
  12623.  
  12624.     *l2 -= k * lmod;
  12625.  
  12626.     *l1 += k * lp;
  12627. }
  12628.  
  12629.  
  12630.  
  12631. yprint (m)
  12632.  
  12633. long  m;
  12634.  
  12635. {
  12636.     if (cnt < n) {
  12637.  
  12638.         if (++col == 6) {
  12639.  
  12640.             col = 1;
  12641.             if (++col1 == 10) {
  12642.  
  12643.                 col1 = 0;
  12644.  
  12645.                 printf ("\n%4d", m % 10);
  12646.  
  12647.             }
  12648.             else
  12649.  
  12650.                 printf ("%2d", m % 10);
  12651.  
  12652.         }
  12653.  
  12654.         else
  12655.  
  12656.             printf ("%d", m);
  12657.         cnt++;
  12658.  
  12659.     }
  12660.  
  12661. }
  12662. ---------------
  12663.  
  12664. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34L40992 Date: 04/17/90
  12665. From: TED GAGLIANO                                          Time: 04:16 am
  12666.   To: ALL                                                   (Read 68 times)
  12667. Subj: PI-PART4
  12668.  
  12669. And here is PART 4+++++++++++++++++++++++++++++++++++++---<TRG>
  12670.  
  12671. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  12672.  
  12673.  
  12674. xprint (m)
  12675.  
  12676. long  m;
  12677.  
  12678. {
  12679.     long  i, wk, wk1;
  12680.  
  12681.  
  12682.  
  12683.     if (m < 8) {
  12684.  
  12685.         for (i = 1; i <= loc;)
  12686.  
  12687.             yprint (stor[i++]);
  12688.         loc = 0;
  12689.  
  12690.     }
  12691.  
  12692.     else
  12693.     if (m > 9) {
  12694.  
  12695.         wk = m / 10;
  12696.  
  12697.         m %= 10;
  12698.  
  12699.         for (wk1 = loc; wk1 >= 1; wk1--) {
  12700.             wk += stor[wk1];
  12701.  
  12702.             stor[wk1] = wk % 10;
  12703.  
  12704.             wk /= 10;
  12705.  
  12706.         }
  12707.  
  12708.     }
  12709.     stor[++loc] = m;
  12710.  
  12711. }
  12712.  
  12713. ---------------
  12714.  
  12715. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34ME3329 Date: 04/18/90
  12716. From: GREGORY WILSON                                        Time: 10:55 am
  12717.   To: ALL                                                   (Read 69 times)
  12718. Subj: MSC VS QUICKC
  12719.  
  12720. Just to satisfy my curiousity and to justify purchasing Microsoft C, what
  12721. is the difference between Quick C 2.0 and Microsoft C 5.1 as far as
  12722. performance, size, ..etc. Is it really worth going out and getting MSC
  12723. when I already have Quick C 2.0? Doesn't QuickC 2.0 use the same libs?
  12724. Anyway...I would appreciate any enlightment from you.
  12725. THanks!
  12726. Gregory Wilson
  12727. ---------------
  12728. Following thread
  12729.  
  12730. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34NN2400 Date: 04/19/90
  12731. From: NESHAM SOFTWARE                                       Time: 07:40 pm
  12732.   To: GREGORY WILSON (Rcvd)                                 (Read 73 times)
  12733. Subj: R: MSC VS QUICKC
  12734.  
  12735.   QuickC uses *.QCL libs I believe. Anyway, MSC 6.0 is on its way and it's
  12736. got quite a bit enhancements from 5.1.
  12737.   Differences between QC and MSC are the debugger, optimization and price!
  12738. I've had problems using QC for large projects. QC comes with 5.1 but only
  12739. the older version - not QC 2.0. OS2 support may be a factor.
  12740. Unless you like spending $$$$ I think TurboC is superior to MSC5.1.
  12741. MSC 6.0 is another story but it will cost $450 list!
  12742.  
  12743.   Tim
  12744. ---------------
  12745. ** Current thread: MSC VS QUICKC
  12746.  
  12747. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34NP3241 Date: 04/19/90
  12748. From: ROBERT BALSOVER                                       Time: 08:54 pm
  12749.   To: NESHAM SOFTWARE (Rcvd)                                (Read 69 times)
  12750. Subj: R: MSC VS QUICKC
  12751.  
  12752. One should also wait to see what *new* bugs are in MSC 6.0
  12753. It could be great, and it could be pandora's box.
  12754. Bob
  12755. ---------------
  12756. ** Current thread: MSC VS QUICKC
  12757.  
  12758. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34NQ0790 Date: 04/19/90
  12759. From: GREGORY WILSON                                        Time: 09:13 pm
  12760.   To: NESHAM SOFTWARE (Rcvd)                                (Read 68 times)
  12761. Subj: R: MSC VS QUICKC
  12762.  
  12763. I have a copy of Turbo C that I borrowed from a friend to try out but have
  12764. not had any time to benchmark the two. What advantages do you know of for
  12765. Turbo C. Since I have already invested in Quick C and about 8 MSC books, I
  12766. will probably stick with it.
  12767. Anyway...thanks for the help!
  12768. Gregory Wilson
  12769. ---------------
  12770. ** Current thread: MSC VS QUICKC
  12771.  
  12772. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34PL2038 Date: 04/20/90
  12773. From: NESHAM SOFTWARE                                       Time: 05:33 pm
  12774.   To: ROBERT BALSOVER (Rcvd)                                (Read 71 times)
  12775. Subj: R: MSC VS QUICKC
  12776.  
  12777.  Agreed. I wonder if they will make us pay for 6.1 bug fixes.
  12778.  
  12779.   Tim
  12780. ---------------
  12781. ** Current thread: MSC VS QUICKC
  12782.  
  12783. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34QD2632 Date: 04/21/90
  12784. From: ROBERT BALSOVER                                       Time: 09:43 am
  12785.   To: NESHAM SOFTWARE (Rcvd)                                (Read 70 times)
  12786. Subj: R: MSC VS QUICKC
  12787.  
  12788. Tim,
  12789. I don't use MSC but if there are new features that I want, I'll wait until
  12790. 6.1 because you know M$ will charge for it.
  12791. Bob
  12792. ---------------
  12793. ** Current thread: MSC VS QUICKC
  12794.  
  12795. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34QE0873 Date: 04/21/90
  12796. From: GRANT ELLSWORTH (Leader)                              Time: 10:14 am
  12797.   To: NESHAM SOFTWARE (Rcvd)                                (Read 71 times)
  12798. Subj: R: MSC VS QUICKC
  12799.  
  12800. Of course they'll have you pay even more $$$ for the 6.1 bug fixes ... and
  12801. then pay even more for the 7.0 fixes for the bugs still in 6.1 ...
  12802.  
  12803. Meanwhile you'll spend hours and hours working with a lame debugger trying
  12804. to find out why your programs don't work ---- and be in the dark for many
  12805. days wondering whether it was your coding or an M$C "feature" which bit
  12806. you.
  12807.  
  12808. M$C any level ... it just ain't worth the time or the money.  Grant
  12809. ---------------
  12810. ** Current thread: MSC VS QUICKC
  12811.  
  12812. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34QG1017 Date: 04/21/90
  12813. From: NESHAM SOFTWARE                                       Time: 12:16 pm
  12814.   To: GRANT ELLSWORTH (Rcvd)                                (Read 69 times)
  12815. Subj: R: MSC VS QUICKC
  12816.  
  12817. The lame debugger will be stronger in 6.0 as it will support the use of
  12818. virtual memory for debugging. We use a product call Softice to allow us to
  12819. run a debugging session that needs more than 640k. With 6.0 we won't need
  12820. such third party products. Codeview will allow browsing of objects like
  12821. the Turbo Debugger. We will have to wait and see the 'truth' of all the
  12822. M$C hype! As they claim it is the FASTEST and TIGHTEST compiler in the
  12823. universe. Yeah, right.
  12824.  
  12825.   Tim
  12826. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  12827.  
  12828. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34MI1547 Date: 04/18/90
  12829. From: ANDY HUBBELL                                          Time: 02:25 pm
  12830.   To: ALL                                                   (Read 74 times)
  12831. Subj: TC 2.0 SOURCE
  12832.  
  12833. I AM A RELATIVELY NOVICE 'C' PROGRAMMER.  I AM CURIOUS TO KNOW IF ANY
  12834. ADVANTAGE COULD BE GAINED BY PURCHASING THE BORLAND TURBO C V2.0 RUNTIME
  12835. LIBRARY SOURCE CODE.  BORLAND SELLS IT FOR ABOUT 150 BUCKS.  IS IT WORTH
  12836. IT ?
  12837.  
  12838. I WELCOM ALL SUGGESTIONS AND/OR COMMENTS PLEASE.
  12839.  
  12840. ANDY
  12841. ---------------
  12842. Following thread
  12843.  
  12844. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34NB3115 Date: 04/19/90
  12845. From: ANDY HUBBELL                                          Time: 07:51 am
  12846.   To: ROBERT BALSOVER (Rcvd)                                (Read 73 times)
  12847. Subj: R: TC 2.0 SOURCE
  12848.  
  12849. BOB,
  12850.  
  12851. Thanks for the reply.  I have not heard of RTL.  Is it public domain ?
  12852. I mainly want to see how some of the library functions are written to
  12853. better help me understand the basics of C.  I have pulled a lot of source
  12854. from the BBS that others have written.  However, most code uses the
  12855. libraries.  Let me know about the RTL and I'll type at you later.
  12856.  
  12857. ANDY
  12858. ---------------
  12859. ** Current thread: TC 2.0 SOURCE
  12860.  
  12861. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34PC0467 Date: 04/20/90
  12862. From: ANDY HUBBELL                                          Time: 08:07 am
  12863.   To: ROBERT BALSOVER (Rcvd)                                (Read 73 times)
  12864. Subj: R: TC 2.0 SOURCE
  12865.  
  12866. Bob,
  12867.  
  12868. Now I feel kind of stupid.  I suppose if I thought about it enough I would
  12869. have figured it out.  Thanks again for the info.
  12870.  
  12871. Andy
  12872. ---------------
  12873. ** Current thread: TC 2.0 SOURCE
  12874.  
  12875. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 351H0486 Date: 05/01/90
  12876. From: ANDY HUBBELL                                          Time: 01:08 pm
  12877.   To: DAVID THOMAS (Rcvd)                                   (Read 84 times)
  12878. Subj: R: TC 2.0 SOURCE
  12879.  
  12880. DAVID,
  12881.  
  12882. THANKS FOR THE REPLY.  I AM STILL NOT SURE THAT I WANT TO SPEND THE MONEY
  12883. TO OBTAIN THE SOURCE WHEN THERE ARE MANY KNOWLEDGEABLE FOLKS RIGHT HERE ON
  12884. THE BBS THAT CAN HELP.  THANKS...
  12885.  
  12886. Andy
  12887. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  12888.  
  12889. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34MS1062 Date: 04/18/90
  12890. From: JOHN ABATTE                                           Time: 11:17 pm
  12891.   To: ALL                                                   (Read 68 times)
  12892. Subj: TURBO GLITCH
  12893.  
  12894. Here's an interesting problem I ran into with TC 2.01. Considering the
  12895. following code frag, why does TC complain that the "Constant is a long" or
  12896. some such silliness:
  12897.  
  12898. #include <stdio.h>
  12899. void main(void)
  12900. {
  12901.   unsigned int x=59009, y=8881;
  12902.   printf("%u decimal or %x hex.\n", x&y, x&y);
  12903. }
  12904.  
  12905. I've obviously declared x to be unsigned, but the compiler keeps nagging
  12906. me about the constant 59009 being a long value.
  12907.  
  12908. Now the interesting part is that if I declare "unsigned int x=0xE681;"
  12909. there's NO PROBLEM!!! It's the same friggin' number!!!
  12910.  
  12911. T'ink I ought to B**ch to Borland?
  12912.  
  12913. This one's got me baffled since I compiled on another machine with no
  12914. warnings with the same compiler setup. MSC didn't complain at all when I
  12915. ran it by him.
  12916.  
  12917. AMAZING STUFF CATAGORY
  12918. Ciao...John
  12919. ---------------
  12920. Following thread
  12921.  
  12922. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34N12610 Date: 04/19/90
  12923. From: ROBERT BALSOVER                                       Time: 12:43 am
  12924.   To: JOHN ABATTE (Rcvd)                                    (Read 68 times)
  12925. Subj: R: TURBO GLITCH
  12926.  
  12927. John,
  12928. If you have a CIS account, I would ask in the BPROGB forem.
  12929. Bob
  12930. ---------------
  12931. ** Current thread: TURBO GLITCH
  12932.  
  12933. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34PM3554 Date: 04/20/90
  12934. From: JOHN ABATTE                                           Time: 06:59 pm
  12935.   To: ROBERT BALSOVER (Rcvd)                                (Read 67 times)
  12936. Subj: R: TURBO GLITCH
  12937.  
  12938. Hi Bob,
  12939.  
  12940. Tanx for the feedback. I figured it out today, though. All I needed to do
  12941. was append a 'U' to the end of the constant as: 59009U so the compiler
  12942. would stop nagging.
  12943.  
  12944. Thanks again.
  12945.  
  12946. John.
  12947. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  12948.  
  12949. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34NS0354 Date: 04/19/90
  12950. From: JIM NICKEL                                            Time: 11:05 pm
  12951.   To: ALL                                                   (Read 72 times)
  12952. Subj: TURBO C MAKEFILES
  12953.  
  12954. I started a project entirely in the Turbo C editor/compiler environment.
  12955. After a short time, I started to run out of memory.
  12956. At that point, I converted my project to use a makefile, but I wonder
  12957. if I can set it up so that the makefile does comparisons between source
  12958. files in one directory, and their associated object files in  another
  12959. directory.  The Turbo C programming environment allows this, but I'm
  12960. not sure how to do it in a makefile.  Here's what my makefile looks like:
  12961.  
  12962. A.EXE:  b.obj c.obj d.obj e.obj f.obj
  12963.    tlink /v /c lib\C0L @lnkfiles.def, a.exe, a.map, lib\cwtt20l +
  12964.                                  lib\emu lib\mathl lib\cl
  12965.  
  12966. .c.obj:
  12967.    tcc -a -f -Iinclude -c -v -w-sus -ml -y $<
  12968.  
  12969. ----------------------------------------------------------------
  12970. My 'lnkfiles.def' file looks like this:
  12971.  
  12972. a b c d e f
  12973. -----------------------------------------------------------
  12974. Any help to unclutter my TurboC base directory would be appreciated.
  12975. Jim
  12976. ---------------
  12977. Following thread
  12978.  
  12979. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34PL2328 Date: 04/20/90
  12980. From: NESHAM SOFTWARE                                       Time: 05:38 pm
  12981.   To: JIM NICKEL (Rcvd)                                     (Read 71 times)
  12982. Subj: R: TURBO C MAKEFILES
  12983.  
  12984.  There is NO need to run out of memory using the environment. Just break
  12985. up your source file. Also you can dump the file you are editing from
  12986. memory. Source files greater than 30,000 bytes should be avoided.
  12987. Sorry, I don't use anything but the environment.
  12988.  
  12989.    Tim
  12990. ---------------
  12991. ** Current thread: TURBO C MAKEFILES
  12992.  
  12993. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34PS1802 Date: 04/20/90
  12994. From: JIM NICKEL                                            Time: 11:30 pm
  12995.   To: NESHAM SOFTWARE (Rcvd)                                (Read 74 times)
  12996. Subj: R: TURBO C MAKEFILES
  12997.  
  12998. I would prefer to work in the TC environment also, but I don't have enough
  12999. memory to run my program from there once I compile and link it.
  13000. Therefore, the incentive to work in the TC environment disapears
  13001. immediately.  I have about 60 modules which are on the average around 10K
  13002. in source code and the largest one is 26K.  The resulting .EXE code is
  13003. about 250K in size.  Turbo C uses about 300K or so, which doesn't leave
  13004. much room for anything else.  I know I could EXPLICITLY do the makefile
  13005. compares on each source code file, but then the appeal of the implicit
  13006. rules of makes also disappears.  I suppose I could move both my source and
  13007. object to a subdirectory under \TC.  Maybe I'll call Borland to see what
  13008. (if anything) they suggest.
  13009. Jim
  13010. ---------------
  13011. ** Current thread: TURBO C MAKEFILES
  13012.  
  13013. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34QE0599 Date: 04/21/90
  13014. From: GRANT ELLSWORTH (Leader)                              Time: 10:10 am
  13015.   To: JIM NICKEL (Rcvd)                                     (Read 72 times)
  13016. Subj: R: TURBO C MAKEFILES
  13017.  
  13018. Jim, Aside from breaking you C program into smaller compilable units (good
  13019. idea) or using header files to contain common typedefs and prototypes, you
  13020. can use the TCC / Makefile environment to compile slightly larger units as
  13021. you suspect.
  13022.  
  13023. To reroute and trigger checking for obj's in directory other than the
  13024. source directory, you MUST specify the output obj directory in the
  13025. Makefile rules.  I usually do this via a defined makefile variable, eg:
  13026.  
  13027. OBJEXE = C:\MYPROGS\OBJEXE\ # <- comment flag necessary to allow \ as
  13028. #                                   last character
  13029. INCL = C:\MYPROGS\INCL\ # <- preserves  \ as last char
  13030.  ....
  13031.  
  13032. $(OBJEXE)myprog.exe: $(OBJEXE)myprog.obj $(OBJEXE)other.obj ..... etc.
  13033.    tlink @myprog.lnk .....
  13034.  
  13035. ......
  13036.  
  13037. $(OBJEXE)myprog.obj: myprog.c $(INCL)myhdr.h $(INCL)other.h .... etc..
  13038.  ....
  13039.  
  13040. Hope this is enough for you to get the gist of it.  Grant
  13041. ---------------
  13042. ** Current thread: TURBO C MAKEFILES
  13043.  
  13044. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34QG0538 Date: 04/21/90
  13045. From: NESHAM SOFTWARE                                       Time: 12:08 pm
  13046.   To: JIM NICKEL (Rcvd)                                     (Read 71 times)
  13047. Subj: R: TURBO C MAKEFILES
  13048.  
  13049.  Well running the .exe within the TC environment is a bit too much for
  13050. poor old DOS. I've never tried that since  I get out of the environment
  13051. first. I wonder if it should swap itself out?
  13052.  
  13053.   Tim
  13054. ---------------
  13055. ** Current thread: TURBO C MAKEFILES
  13056.  
  13057. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34QI1670 Date: 04/21/90
  13058. From: JIM NICKEL                                            Time: 02:27 pm
  13059.   To: GRANT ELLSWORTH (Rcvd)                                (Read 72 times)
  13060. Subj: R: TURBO C MAKEFILES
  13061.  
  13062. Hi Grant.
  13063. I suspected I could do something like that, but I didn't want to have to
  13064. specify EVERY file in my makefile definition.  Currently I use the
  13065. built-in rule of:
  13066. .c.obj
  13067. to say that ALL .obj files depend on their coresponding .c file.
  13068. I think I might punt and move everything (source and object to a new
  13069. directory).
  13070. Thanks for the idea though.
  13071. Jim
  13072. ---------------
  13073. ** Current thread: TURBO C MAKEFILES
  13074.  
  13075. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34QI1905 Date: 04/21/90
  13076. From: JIM NICKEL                                            Time: 02:31 pm
  13077.   To: NESHAM SOFTWARE (Rcvd)                                (Read 74 times)
  13078. Subj: R: TURBO C MAKEFILES
  13079.  
  13080. I started to work ENTIRELY in the TC environment and it was really neat.
  13081. I could write code, test it, edit it, run it again, all without leaving
  13082. the TC editor window.  Now that my program is getting bigger, I guess it's
  13083. kinda like squeezing blood out of a turnip.  I had heard that it is
  13084. possible to move TC up to extended/expanded memory on a 386 to gain a
  13085. couple of extra hundred K for your program, but I can't say that I've
  13086. actually seen it done.
  13087. CUL
  13088. Jim
  13089. ---------------
  13090. ** Current thread: TURBO C MAKEFILES
  13091.  
  13092. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34RE0459 Date: 04/22/90
  13093. From: GRANT ELLSWORTH (Leader)                              Time: 10:07 am
  13094.   To: JIM NICKEL (Rcvd)                                     (Read 74 times)
  13095. Subj: R: TURBO C MAKEFILES
  13096.  
  13097. Jim, I didn't illustrate it right for the global  rule, but, you can
  13098. use the global rule as well.  I just haven't used it that way.
  13099.  
  13100. What I do is this:
  13101.  
  13102. CM1 = TCC ........
  13103.  
  13104. $(OBJEXE)myprog.exe: $(OBJEXE)myprog.obj .....
  13105.    tlink @myprog.lnk
  13106.  
  13107. $(OBJEXE)myprog.obj: myprog.c  .....
  13108.     $(CM1)
  13109.  
  13110. That way I can set the global compile rule in the CM1 variable
  13111.  
  13112. I did try to use the global .c.obj construct, but got it fouled up.
  13113. There is a way to do it ... or should be ...
  13114.  
  13115. grant
  13116. ---------------
  13117. ** Current thread: TURBO C MAKEFILES
  13118.  
  13119. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34RE0637 Date: 04/22/90
  13120. From: GRANT ELLSWORTH (Leader)                              Time: 10:10 am
  13121.   To: JIM NICKEL (Rcvd)                                     (Read 73 times)
  13122. Subj: R: TURBO C MAKEFILES
  13123.  
  13124. Jim, I wonder ... can you get your program compiled in the IDE (no run)?
  13125. If so, why not just compile to the .exe form and run it from the command
  13126. line?  For debugging, though, you'd have to use the stand-alone debugger.
  13127.  
  13128. grant
  13129. ---------------
  13130. ** Current thread: TURBO C MAKEFILES
  13131.  
  13132. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34RF3272 Date: 04/22/90
  13133. From: JIM NICKEL                                            Time: 11:54 am
  13134.   To: GRANT ELLSWORTH (Rcvd)                                (Read 71 times)
  13135. Subj: R: TURBO C MAKEFILES
  13136.  
  13137. I agree, there SHOULD be a way to do it with the global .c.obj construct,
  13138. but I haven't figured it out yet either.
  13139. CYA
  13140. Jim
  13141. ---------------
  13142. ** Current thread: TURBO C MAKEFILES
  13143.  
  13144. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34RF3586 Date: 04/22/90
  13145. From: JIM NICKEL                                            Time: 11:59 am
  13146.   To: GRANT ELLSWORTH (Rcvd)                                (Read 74 times)
  13147. Subj: R: TURBO C MAKEFILES
  13148.  
  13149. Yes, I can do a compile/link from within the IDE and that is how I
  13150. started.  I originally had my output directory as C:\TC\OUTPUT, while all
  13151. of my source code was at C:\TC.  That was no problem for the IDE to
  13152. determine which (if any) files needed to be re-compiled.  When I switched
  13153. to the command line stuff, it required me to move all of my stuff back to
  13154. the C:\TC directory.  No big deal, but I figured there "must" be a way
  13155. to keep the two separated if the IDE can do it.  I guess the smart thing
  13156. to do is really to set up a subdirectory under C:\TC that has both source
  13157. and object code in it.
  13158. Jim
  13159. ---------------
  13160. ** Current thread: TURBO C MAKEFILES
  13161.  
  13162. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34SM1257 Date: 04/23/90
  13163. From: GRANT ELLSWORTH (Leader)                              Time: 06:20 pm
  13164.   To: JIM NICKEL (Rcvd)                                     (Read 73 times)
  13165. Subj: R: TURBO C MAKEFILES
  13166.  
  13167. Jim, The makefile example I left has a "work_around".  However, I think
  13168. you can do this:
  13169.  
  13170. OUTPUT=C:\MYAPPS\EXE\ # ...etc.
  13171.  
  13172. c.obj:
  13173.   tcc -mx -o$(OUTPUT)$&.obj .... $<
  13174. ....
  13175. $(OUTPUT)myprog.obj: myprog.c
  13176.  
  13177. $(OUTPUT)other.obj: other.c ....
  13178.  
  13179. Grant
  13180. ---------------
  13181. ** Current thread: TURBO C MAKEFILES
  13182.  
  13183. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34SR3461 Date: 04/23/90
  13184. From: JIM NICKEL                                            Time: 10:57 pm
  13185.   To: GRANT ELLSWORTH (Rcvd)                                (Read 73 times)
  13186. Subj: R: TURBO C MAKEFILES
  13187.  
  13188. That isn't really what I'm looking for Grant.  I wanted to avoid supplying
  13189. EACH filename in my makefile, and somehow perhaps set some environmental
  13190. variable prior to running TC.  Thanks for thinking about it though.
  13191. Jim
  13192. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  13193.  
  13194. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34U11230 Date: 04/25/90
  13195. From: RAY TWEEDALE                                          Time: 12:20 am
  13196.   To: ALL                                                   (Read 77 times)
  13197. Subj: C HELP
  13198.  
  13199. I am new to C programming and have run into a problem.  In the code that
  13200. follows, i am getting a "filename" (line 5&6) from the user and then
  13201. reading
  13202. the file to find a specific string (line 16&17).  The problem i have is
  13203. that
  13204. when i watch the variable "c" in my debugger and it matches the string
  13205. literal,
  13206. line 18 never executes.
  13207.  
  13208. My first thought was that i should have put "*c" instead of "c".  But then
  13209. i get
  13210. an indirection error while compiling.  I don't have a vast reference
  13211. available
  13212. and from what i do have i don't see anything wrong with line 17.
  13213.  
  13214. I need this program to work soon and have come looking here for advice
  13215. Thanks for any replys.
  13216.  
  13217. 1     FILE *fp1;
  13218. 2     char oneword[81],filename[11];
  13219. 3     char *c, yn ;
  13220. ...  /* a switch in here to get general info */
  13221. ...  /* general program info screens         */
  13222. 4
  13223. 5          printf("Enter database filename --> ");
  13224. 6          scanf("%s",filename);         /* read the desired filename */
  13225. 7          fp1 = fopen(filename,"r");
  13226. 8             if(fp1 == NULL)
  13227. 9                {
  13228. 10                printf("File %s does not exist. Please try
  13229. again.\n",fp1);
  13230. 11                     goto file_entry ;
  13231. 12                }
  13232. 13
  13233. 14          do
  13234. 15            {
  13235. 16            c = fgets(oneword,11,fp1); /* get one line from the file */
  13236.  
  13237. 17--------------------> if (c  == "TYPE: AI\n") /* why doesn't this
  13238. work!!!!!!!*/
  13239.  
  13240. 18                 printf("%s",c );    /* display it on the monitor  */
  13241. 19
  13242. 20            }
  13243. 21          while (c != NULL);          /* repeat until NULL          */
  13244. 22          }
  13245. 23      fclose(fp1);
  13246.  
  13247. ray tweedale
  13248. ---------------
  13249. Following thread
  13250.  
  13251. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34U13056 Date: 04/25/90
  13252. From: OTTO PORTER                                           Time: 12:50 am
  13253.   To: RAY TWEEDALE (Rcvd)                                   (Read 80 times)
  13254. Subj: R: C HELP
  13255.  
  13256. Ray,
  13257.  
  13258. 16            c = fgets(oneword,11,fp1); /* get one line from the file */
  13259.  
  13260. The above line is putting the string that is returned in the char array
  13261. 'oneword'.  'c' will contain a 1 if the function returned successfully
  13262. and a zero otherwise.
  13263. Your test in line 17 should be:
  13264.     IF ( stricmp( oneword, "your text" )
  13265.          'your line 18'
  13266.  
  13267. This is the function from TurboC.  You may have something different
  13268. depending on the compiler you have.  Whatever it is called, you
  13269. should look for a function that compares two strings, preferably,
  13270. case-insensitive.
  13271.  
  13272. Hope this helps.
  13273.  
  13274. Otto Porter
  13275. ---------------
  13276. ** Current thread: C HELP
  13277.  
  13278. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34VR1428 Date: 04/26/90
  13279. From: MARK TELLIER                                          Time: 10:23 pm
  13280.   To: RAY TWEEDALE (Rcvd)                                   (Read 76 times)
  13281. Subj: R: C HELP
  13282.  
  13283. Ray,
  13284.  
  13285. I noticed a couple of things in your program.
  13286.  
  13287. #1.  Line 10 (the printf) uses a %s to display the filename, but the
  13288. variable references the file pointer variable (fp1).  I believe you want
  13289. to use the variable "filename"
  13290.  
  13291. #2.  BTW, the variable "filename" should be a little longer.  Filenames
  13292. are eight character in name, three characters in file type plus period
  13293. separating these two parts.  Even without a character for the terminating
  13294. NULL character, your short on storage space.  This still leaves nothing
  13295. for drive and path info.
  13296.  
  13297. #3.  The previous message explaing the string compare needed to find the
  13298. data your looking for.
  13299.  
  13300. #4.  I think there is also a problem with your fgets statement.
  13301. Syntax wise, its ok, but if you read 11 (or more characters) without
  13302. reading the complete line at once, you might read just part of the file
  13303. name on one read (and fail the comparison test) and read the remaining
  13304. portion of the filename on the next read (again failing the test).
  13305.  
  13306. I hope these hints help (and are correct!).
  13307.  
  13308. - mwt -
  13309. ---------------
  13310. ** Current thread: C HELP
  13311.  
  13312. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34VS0473 Date: 04/26/90
  13313. From: RAY TWEEDALE                                          Time: 11:07 pm
  13314.   To: OTTO PORTER (Rcvd)                                    (Read 71 times)
  13315. Subj: R: C HELP
  13316.  
  13317. Otto,
  13318.  
  13319. I am using MS-QC2.  My manual says that fgets returns a pointer to a
  13320. string if successful or NULL if not or EOF. Then after this i am assigning
  13321. the return to "c" which i declared a pointer.  At least that is what i
  13322. thought and my debugger tells me when i watch the variables.
  13323.  
  13324. 16      c = fgets(oneword,11, fp1)
  13325.     i read the above statement as assign to the variable "c" the string
  13326. stored at "oneword" as determined by fgets.  there shouldn't be any
  13327. true/false condition here..!!??
  13328.  
  13329. I thought about using the stricmp() function.  I still would like to know
  13330. why what i have doesn't work.
  13331.  
  13332. Thanks for the reply.
  13333.  
  13334. ray
  13335. ---------------
  13336. ** Current thread: C HELP
  13337.  
  13338. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34W30656 Date: 04/27/90
  13339. From: PAUL MCKENZIE                                         Time: 03:10 am
  13340.   To: RAY TWEEDALE (Rcvd)                                   (Read 75 times)
  13341. Subj: R: C HELP
  13342.  
  13343. Ray,
  13344. A string is nothing more than an *array* of characters.  In C, you cannot
  13345. compare an array of a certain type with another array of the same type
  13346. with only one test for equality.  You must compare each element until a
  13347. sentinel value is reached, or when a difference is detected when comparing 
  13348. values.  In C, the sentinel character for strings is the NULL.
  13349. strncmp() and strnicmp() compares two character strings until
  13350. a difference is detected, or the NULL is reached.  strncmp() is case
  13351. sensitive, while strnicmp() isn't.
  13352. Hope this helps.
  13353.                      Paul McKenzie
  13354. ---------------
  13355. ** Current thread: C HELP
  13356.  
  13357. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34XG3275 Date: 04/28/90
  13358. From: RAY TWEEDALE                                          Time: 12:54 pm
  13359.   To: MARK TELLIER (Rcvd)                                   (Read 69 times)
  13360. Subj: R: C HELP
  13361.  
  13362. Mark,
  13363.  
  13364. I tried t osend you a reply when i got this message but kept getting
  13365. knocked off the board half way thru.
  13366.  
  13367. Where is Brwon Deer ? Is that near Gledndale?  <grin>
  13368.  
  13369. Your comment about my Line 10 was correct. I should be useing "filename"
  13370. instead of "fp1".  I hadn't tried that condition yet so thanks for finding
  13371. it.
  13372.  
  13373. #2 I should allow more storage space for the filename[].  I forgot about
  13374. the period.  I included in the info screens that the file should be in hte
  13375. current directory.  I suppose it wouldn't hurt to include a path.  Maybe
  13376. later.
  13377.  
  13378. #3  Not sure what you meant by this comment.
  13379.  
  13380. #4  Line 16  c=fgets(oneword, 11,fp1);
  13381.     does grab each line of the file and i see it in my locals screen of
  13382.     the debugger.  The variable "c" gets assigned from fgets the value i'm
  13383.     looking for, but the equality check i do in LINE 17 never becomes
  13384.     true.  That is the problem i'm having.  I get the file in but don't
  13385.     pick out what i want.  The way it is now it just goes thru every line
  13386.     of the file and quits.
  13387.  
  13388. Thanks for your comments.  Soon as i'm off here i'm gonna dig into this
  13389. and figure this out.
  13390.  
  13391. ray
  13392. ---------------
  13393. ** Current thread: C HELP
  13394.  
  13395. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34XH0819 Date: 04/28/90
  13396. From: RAY TWEEDALE                                          Time: 01:13 pm
  13397.   To: PAUL MCKENZIE (Rcvd)                                  (Read 69 times)
  13398. Subj: R: C HELP
  13399.  
  13400. Paul,
  13401.  
  13402. Thats the answer i needed! Thanks.  I am looking at one of my references
  13403. and in big bold letters it says ," C DOES NOT PROVIDE ANY OPERATORS FOR
  13404. PROCESSING AN ENTIRE STRING OF CHARACTERS AS A UNIT."
  13405.  
  13406. Ok thats lesson #3 for me in what not to do!  Hopefully my mistakes will
  13407. be able to be counted on two hands!  Thanks again for setting me straight
  13408. on what was staring me right in the face.  I will incorporate the stricmp.
  13409.  
  13410. Thanks again.
  13411.  
  13412. ray tweedale
  13413. ---------------
  13414. ** Current thread: C HELP
  13415.  
  13416. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34Z11121 Date: 04/30/90
  13417. From: OTTO PORTER                                           Time: 12:18 am
  13418.   To: RAY TWEEDALE (Rcvd)                                   (Read 76 times)
  13419. Subj: R: C HELP
  13420.  
  13421. What the function RETURNS is not related to what the function DOES.
  13422. In this case the function RETURNS a pointer to 'oneword' or NULL if
  13423. unsuccessful.  Therefore, if successful, the char pointer 'c' contains
  13424. the ADDRESS of the first character in the string contained in  'oneword'.
  13425. What the function DOES is copy the string received from the file to
  13426. the char array 'oneword'.  Therefore if you want to examine or compare
  13427. the contents of the string you can do it the way I described in my
  13428. previous message.
  13429.  
  13430. Otto
  13431. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  13432.  
  13433. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34UH1948 Date: 04/25/90
  13434. From: CHUCK BOWMAN                                          Time: 01:32 pm
  13435.   To: ALL                                                   (Read 74 times)
  13436. Subj: PROGRAM TOOLS
  13437.  
  13438. Are there Public Domain C modules for matrix algebra? Specifically to
  13439. calculate the eigenvectors of a matrix? Where is a good place to look?
  13440. ---------------
  13441. Following thread
  13442.  
  13443. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34VR1603 Date: 04/26/90
  13444. From: MARK TELLIER                                          Time: 10:26 pm
  13445.   To: CHUCK BOWMAN (Rcvd)                                   (Read 73 times)
  13446. Subj: R: PROGRAM TOOLS
  13447.  
  13448. Chuck,
  13449.  
  13450. If you find any tools like your looking for, I would be interested to hear
  13451. about them.  My first days working on my MSEE degree required a lot of
  13452. work using the type of tools your looking for.  I wrote some in BASIC back
  13453. then, but would like to have some in C available.
  13454.  
  13455. - mwt -
  13456. ---------------
  13457. ** Current thread: PROGRAM TOOLS
  13458.  
  13459. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34ZR3310 Date: 04/30/90
  13460. From: DAVID THOMAS                                          Time: 10:55 pm
  13461.   To: CHUCK BOWMAN (Rcvd)                                   (Read 73 times)
  13462. Subj: R: PROGRAM TOOLS
  13463.  
  13464. Chuck:
  13465.   Maybe the C User's Journal, which has an extensive public domain
  13466. library, would be a good bet for a matrix algebra/linear systems library.
  13467. The address is:
  13468.       The C user's Journal
  13469.       2120 W. 25th Street, Suite B
  13470.       Lawence, KA 66047
  13471.       (913) 841-1631
  13472.  
  13473. Also, maybe the Public Brand Software catalog, which has
  13474. shareware/freeware offerings for $5.00 a disk, might have something.  I
  13475. know they have a version of "Matlab", but if you need the eigenvector
  13476. routine as part of an application that is not the way to go. The
  13477. address for a copy of the catalog is
  13478.  
  13479. Public Brand Software
  13480. PO Box 51315
  13481. Indianapolis, IN 46251
  13482. 1-800-426-DISK
  13483.  
  13484. David
  13485. ---------------
  13486. ** Current thread: PROGRAM TOOLS
  13487.  
  13488. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 354B2256 Date: 05/04/90
  13489. From: VICTOR DURA                                           Time: 07:37 am
  13490.   To: DAVID THOMAS (Rcvd)                                   (Read 71 times)
  13491. Subj: R: PROGRAM TOOLS
  13492.  
  13493. Chuck:
  13494.   If you have access to a FORTRAN compiler, you might consider finding
  13495. FORTRAN routines to do what you want, then compiling the FORTRAN
  13496. routines, then linking and calling them from your C program. DDJ had
  13497. a good article on this technique several months ago using Lattice
  13498. (I think?) C and FORTRAN compilers as an example. I've done it
  13499. with MS C and FORTRAN.
  13500.   There's literally millions of lines of FORTRAN stuff out there,
  13501. publicly available, for doing math, science, and engineering stuff;
  13502. so you ought to be able to find something. If not, leave me a
  13503. note, and I'll pull something out of my archive.
  13504. ...Vic Dura
  13505. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  13506.  
  13507. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34VF1706 Date: 04/26/90
  13508. From: STEVEN KRUEGER                                        Time: 11:28 am
  13509.   To: ALL                                                   (Read 72 times)
  13510. Subj: C CROSS COMPILER 68000
  13511.  
  13512. I'm looking for a c compiler for the motorola 68000 that can be compiled
  13513. and linked on a pc and be assembled into code for eprom programming.
  13514. If you know where to get this or have it please call me at (414) 444-6060.
  13515. thank you steve
  13516. ---------------
  13517. Following thread
  13518.  
  13519. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34ZS0172 Date: 04/30/90
  13520. From: DAVID THOMAS                                          Time: 11:02 pm
  13521.   To: STEVEN KRUEGER (Rcvd)                                 (Read 74 times)
  13522. Subj: R: C CROSS COMPILER 68000
  13523.  
  13524. Steve:
  13525.   Avocet has a crosscompiler hosted on the PC aimed at 68000 targets.
  13526.  
  13527.   Avocet Systems Inc.
  13528.   120 Union Street
  13529.   PO Box 490
  13530.   Rockport, Maine 04856
  13531.   1-800-448-8500
  13532.  
  13533. Or check out a recent copy of Embedded Systems Programming, which is a
  13534. Miller-Freeman publication aimed at microprocessor driven products.
  13535.  
  13536. David
  13537. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  13538.  
  13539. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34WD1293 Date: 04/27/90
  13540. From: GREGORY WILSON                                        Time: 09:21 am
  13541.   To: ALL                                                   (Read 68 times)
  13542. Subj: C DATABASE LIBS
  13543.  
  13544. I am looking for a good collection of Database functions for MSC. I would
  13545. like something of the quality of CXL that is well documented. Any
  13546. suggestions?
  13547. Thanks in advance!
  13548. Gregory Wilson
  13549. ---------------
  13550. Following thread
  13551.  
  13552. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34YI3070 Date: 04/29/90
  13553. From: JEFF NOWLAND                                          Time: 02:51 pm
  13554.   To: GREGORY WILSON (Rcvd)                                 (Read 69 times)
  13555. Subj: R: C DATABASE LIBS
  13556.  
  13557. gREG.
  13558. Try dbVista.  Its the fastest and most complete library I've ever seen.
  13559. Can handle very complex databases(ie up to 255 files with 16.7 million
  13560. records per file), uses a combination of b-tree indexing and network model
  13561. set relationships.  Libraries are available for many compilers and
  13562. OpSystems.  You can specify access methods to be OneUser,Shared Or
  13563. ExclusiveAccess(diff between OneUser & Exclusive is that OneUser runs
  13564. runs on single user work stations and Exclusive locks the database to keep
  13565. other stations out). Source code can be purchased(expensive albeit).
  13566. They've really got their stuff together. You can order from
  13567. Raima(1-800-327-2462). I've been using it for about 2 years and have seen
  13568. nothing that would entice me into changing.
  13569. JDNowland
  13570. ---------------
  13571. ** Current thread: C DATABASE LIBS
  13572.  
  13573. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 34YP0148 Date: 04/29/90
  13574. From: GREGORY WILSON                                        Time: 08:02 pm
  13575.   To: JEFF NOWLAND (Rcvd)                                   (Read 71 times)
  13576. Subj: R: C DATABASE LIBS
  13577.  
  13578. Jeff,
  13579. THanks! I have not tried that one yet! WIll give it a shot.
  13580. Thanks again,
  13581. Gregory Wilson
  13582. ---------------
  13583. ** Current thread: C DATABASE LIBS
  13584.  
  13585. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 353P2526 Date: 05/03/90
  13586. From: JIM MONROE                                            Time: 08:42 pm
  13587.   To: GREGORY WILSON (Rcvd)                                 (Read 71 times)
  13588. Subj: R: C DATABASE LIBS
  13589.  
  13590. I have been using the "c/database toolchest" from MIX. It is wuite
  13591. complete, any I beleive only about $20 - $30.
  13592. ---------------
  13593. ** Current thread: C DATABASE LIBS
  13594.  
  13595. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 353Q0211 Date: 05/03/90
  13596. From: GREGORY WILSON                                        Time: 09:03 pm
  13597.   To: JIM MONROE (Rcvd)                                     (Read 70 times)
  13598. Subj: R: C DATABASE LIBS
  13599.  
  13600. Thanks! Will look into it. Is there a Public Domain trial version?
  13601. THanks again,
  13602. Gregory Wilson
  13603. ---------------
  13604. ** Current thread: C DATABASE LIBS
  13605.  
  13606. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35IS1096 Date: 05/14/90
  13607. From: JIM MONROE                                            Time: 11:18 pm
  13608.   To: GREGORY WILSON (Rcvd)                                 (Read 73 times)
  13609. Subj: R: C DATABASE LIBS
  13610.  
  13611. I don't know, I have been very satisfied with it and it is quite
  13612. reasonable in price.  The folks down in texas also have been very helpful.
  13613. Jim
  13614. //
  13615. s
  13616. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  13617.  
  13618. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 351S3420 Date: 05/01/90
  13619. From: JONATHAN CROCKETT                                     Time: 11:57 pm
  13620.   To: ALL                                                   (Read 78 times)
  13621. Subj: BUSS SPEED
  13622.  
  13623.   Hello, I need some rather technical help. I've been helping a friend with
  13624. a specialized data taking package. I write assembler code to be called by
  13625. his fortran. The problem: For his software to work correctly, the program
  13626. must know the buss speed. Not the clock speed, but the actual speed (in
  13627. Mhz) the computer talks to prototype cards via ports. Can this speed be
  13628. figured by software? And if so I would like to know how, or know where to
  13629. find out. Any help would be appreciated. Thanx.
  13630. ---------------
  13631. Following thread
  13632.  
  13633. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 352P3018 Date: 05/02/90
  13634. From: LARRY BRADSHAW                                        Time: 08:50 pm
  13635.   To: JONATHAN CROCKETT (Rcvd)                              (Read 74 times)
  13636. Subj: R: BUSS SPEED
  13637.  
  13638. Hello.
  13639.  
  13640. PC-AT buss speeds are standard 8.something MHZ. Every system that does not
  13641. adhere to this std must utilize cards that run at the speed the system
  13642. does, like on those 16mhz buss speed, 33mhz cpu clock speed systems.
  13643.  
  13644. I do not know how to "poll" the buss speed. However, I suggest that if you
  13645. use the ISA standard 8.? MHZ buss speed you will do fine. Most of the 486
  13646. systems I have reviewed specs on acutally use the 8.? mhz buss speed. That
  13647. way they are compatible with existing add-in boards.
  13648.  
  13649. Sorry, but I don't recall the actual number for the ISA std buss speed but
  13650. it should be the same for all 100% compatible IBM PC-ATs, including yours.
  13651.  
  13652.  Hope this helps.
  13653.  
  13654.  Larry
  13655. ---------------
  13656. ** Current thread: BUSS SPEED
  13657.  
  13658. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 354P1739 Date: 05/04/90
  13659. From: JONATHAN CROCKETT                                     Time: 08:29 pm
  13660.   To: LARRY BRADSHAW (Rcvd)                                 (Read 73 times)
  13661. Subj: R: BUSS SPEED
  13662.  
  13663. Thank you for your response, every bit of information is helpful.
  13664.  
  13665.  Jonathan.
  13666. ---------------
  13667. ** Current thread: BUSS SPEED
  13668.  
  13669. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35DP0506 Date: 05/09/90
  13670. From: LARRY BRADSHAW                                        Time: 08:08 pm
  13671.   To: JONATHAN CROCKETT (Rcvd)                              (Read 69 times)
  13672. Subj: R: BUSS SPEED
  13673.  
  13674. no problem.   glad I could help.  If that isn't clear holler & I'll try to
  13675. dig up some dece references for you to look at....
  13676.  
  13677. Larry.
  13678. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  13679.  
  13680. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 354G1203 Date: 05/04/90
  13681. From: GREGORY WILSON                                        Time: 12:20 pm
  13682.   To: ALL                                                   (Read 72 times)
  13683. Subj: MSC CODE SIZE HELP
  13684.  
  13685. Help!
  13686. I use Microsoft C 5.1 and Quick C 2.0 and have been getting frustrated
  13687. about code size (executable code size). I have noticed that if I write a
  13688. program with only 5 or 6 lines that uses 1 function from TIME.H, the code
  13689. size will be about 25K even if I optimize (-Os). Is there anything I can
  13690. do to shrink the code size and eliminate the unneeded stuff? I have a
  13691. friend that uses Turbo Pascal and he can write an equivalent program that
  13692. generates an executable file of about 5K! What gives?
  13693. I would appreciate any explanation you could offer.
  13694. Thanks in advance!
  13695. Gregory Wilson
  13696. ---------------
  13697. Following thread
  13698.  
  13699. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 354R1295 Date: 05/04/90
  13700. From: RON FOX                                               Time: 10:21 pm
  13701.   To: GREGORY WILSON (Rcvd)                                 (Read 74 times)
  13702. Subj: R: MSC CODE SIZE HELP
  13703.  
  13704. I don't think that the problem is necessarily with MSC, but with the
  13705. linker.  I believe that the MS linker does not do intellegent linking and
  13706. includes the object modules in the LIB file whether they are used or not.
  13707. You might be able to pull out only those object modules that you need and
  13708. create your own, optimized LIB file for that particular application.
  13709. Ron
  13710. ---------------
  13711. ** Current thread: MSC CODE SIZE HELP
  13712.  
  13713. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 354S0867 Date: 05/04/90
  13714. From: ROBERT BALSOVER                                       Time: 11:14 pm
  13715.   To: RON FOX (Rcvd)                                        (Read 74 times)
  13716. Subj: R: MSC CODE SIZE HELP
  13717.  
  13718. Ron,
  13719. LIB doesn't link in object files that aren't used, Turbo Pascal uses a
  13720. different method than most compilers.  Those TPU's that it creates makes
  13721. it able to remove unused routines in the files.  Turbo Pascal is the only
  13722. compiler that I know of that does that.
  13723. Bob
  13724. ---------------
  13725. ** Current thread: MSC CODE SIZE HELP
  13726.  
  13727. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35AI2171 Date: 05/06/90
  13728. From: JEFF NOWLAND                                          Time: 02:36 pm
  13729.   To: ROBERT BALSOVER (Rcvd)                                (Read 70 times)
  13730. Subj: R: MSC CODE SIZE HELP
  13731.  
  13732. How does the program report its results?  If you use printf, you can mark
  13733. down 20k right there. If you don't need to format the output, use puts
  13734. instead and you might solve the problem.
  13735. JDNowland.
  13736. ---------------
  13737. ** Current thread: MSC CODE SIZE HELP
  13738.  
  13739. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35AQ1751 Date: 05/06/90
  13740. From: RON FOX                                               Time: 09:29 pm
  13741.   To: ROBERT BALSOVER (Rcvd)                                (Read 68 times)
  13742. Subj: R: MSC CODE SIZE HELP
  13743.  
  13744. Bob
  13745. After sending the message, I did some experimentation with various
  13746. versions on LINK.EXE and modified LIB files.  The size of the executible
  13747. file did not change.
  13748. I should have known better.
  13749. Thankx
  13750. Ron
  13751. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  13752.  
  13753. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 355L1878 Date: 05/05/90
  13754. From: TOM FELLER                                            Time: 05:31 pm
  13755.   To: ALL                                                   (Read 77 times)
  13756. Subj: MICROSCHLOCK C
  13757.  
  13758. The company I work for just tried to convert from Turbo C to Microsoft C
  13759. to see if we would get a smaller program. Well we tried all the possible
  13760. combinations of optimization settings and Microsoft C always made code
  13761. that was about 10% larger than Turbo C. Another thing we found, with
  13762. Microsoft C memory gets fragmented badly. Our program allocates and frees
  13763. memory frequently and under Microsoft C our testing department could run
  13764. the program out of memory in just a few steps. That same program will run
  13765. all day under Turbo C with no problems. I called the Microsoft Tec support
  13766. line and I found out that Microsoft C allocates memory from DOS in 8k
  13767. chunks and when memory is freed it is just marked as free, it is never
  13768. returned to the operating system. I asked if this could fragment memory
  13769. and he said "Yes, it will, you have to keep track of that". Wow, and I
  13770. thought that was what a runtime library was for, how foolish of me to
  13771. think I could use malloc and free without "keeping track" of memory and
  13772. second guessing the Microsoft runtime library. We will continue to use
  13773. Turbo C, a far superior product.
  13774. P.S. Why can't you initialize a character array inside a function with
  13775. Microsoft C?
  13776. Answer: It's because the compiler sucks!
  13777. \Tom Feller\ A.K.A. Turbo Tom
  13778. ---------------
  13779. Following thread
  13780.  
  13781. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35AS1243 Date: 05/06/90
  13782. From: GRANT ELLSWORTH (Leader)                              Time: 11:20 pm
  13783.   To: TOM FELLER (Rcvd)                                     (Read 71 times)
  13784. Subj: R: MICROSCHLOCK C
  13785.  
  13786. I followed a dialog somewhere in recent memory on M$C vs TC heap
  13787. management.  I think your experience confirmed the gist of that discus-
  13788. sion.  As I recollect, M$C did a better job of keeping track of how much
  13789. memory was still available for use, while TC did a much better job of
  13790. getting freed memory back in circulation and did some level of "garbage"
  13791. collection to re-use memory from the heap faster.  Another aspect was that
  13792. applications which did a lot of (far)malloc() and free() over the course
  13793. of a run would do better with the TC heap management routines.
  13794.  
  13795. I wonder if the M$C gang addressed the issue in the somewhat touted new
  13796. 6.0 release (where it is alleged that CrudView finally is as flexible and
  13797. useful a debugging tool as TD).
  13798.  
  13799. For my part, I've found too many other holes and problems with M$C
  13800. generated code to feel comfortable with any production system built with
  13801. it unless the testing/verification has tested every code path from every
  13802. angle.  Grant
  13803. ---------------
  13804. ** Current thread: MICROSCHLOCK C
  13805.  
  13806. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35DC2244 Date: 05/09/90
  13807. From: THOMAS ZERUCHA                                        Time: 08:37 am
  13808.   To: TOM FELLER (Rcvd)                                     (Read 75 times)
  13809. Subj: R: MICROSCHLOCK C
  13810.  
  13811. Try Watcom.  You may want to wait for 8.0, but apparently it's free if you
  13812. get 7.0 at this point.  We went from Microsoft C 5.1 to Watcom 7.0.  The
  13813. executable was 20% smaller and 50-75% faster (your actual mileage may vary
  13814. - this was an image processing application).
  13815.    Microsoft has a bug in malloc().  DDJ had an article on it along with
  13816. some fixer code.  Apparently it doesn't recombine blocks it allocates,
  13817. so if you allocate in 4K blocks until there is no room left, then free
  13818. them, you won't be able to allocate any block >4K.  I haven't looked
  13819. deeply enough to verify this (since Watcom works perfectly).
  13820.      Also, Topspeed is supposed to be good, but they haven;t been around
  13821. as long as Watcom, and I haven't used their compiler.
  13822. .
  13823. ---------------
  13824. ** Current thread: MICROSCHLOCK C
  13825.  
  13826. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35DQ1539 Date: 05/09/90
  13827. From: GRANT ELLSWORTH (Leader)                              Time: 09:25 pm
  13828.   To: THOMAS ZERUCHA (Rcvd)                                 (Read 76 times)
  13829. Subj: R: MICROSCHLOCK C
  13830.  
  13831. Tom, To illustrate the wider acceptance of Watcom C as an alternative to
  13832. Walla Walla C ... The Lotus Magellan product was implemented mostly in
  13833. WatcomC.  One of the authors described WatcomC as "awesome".
  13834.  
  13835. I have WC7.0 and use it as my "high efficiency" compiler.  I've not yet
  13836. gotten an upgrade notice from the Watcom folks.  I purchased WC shortly
  13837. after it came out and took all the upgrades except for WC386.  Have you
  13838. received an upgrade notice or do you know somebody who has?  Grant
  13839. ---------------
  13840. ** Current thread: MICROSCHLOCK C
  13841.  
  13842. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35DS0061 Date: 05/09/90
  13843. From: RON FOX                                               Time: 11:01 pm
  13844.   To: GRANT ELLSWORTH (Rcvd)                                (Read 72 times)
  13845. Subj: R: MICROSCHLOCK C
  13846.  
  13847. Grant,
  13848. I have been stuck with MSC since 4.0 and would love to switch to
  13849. something else.  I have to supply source for 99% of all of the software
  13850. that I write and all of my customers have MSC and don't want to have to
  13851. make any changes to the source to compile it.  In that regard, do you know
  13852. of the relative compatability between MSC and Watcom?
  13853. Also, in the last program that I wrote, I have to manipulate dynamic
  13854. arrays ranging in size from 256Bytes to 250K.  I found that Malloc, either
  13855. the near or far version, would fragment memory so that after two
  13856. iterations of the program, I would be out of memory.  Changing all of the
  13857. malloc calls to either calloc or halloc, depending on the size of the
  13858. array needed, cleared up the memory fragmentation.
  13859. I have MSC 6.0, but have not had the time to test the malloc fragmentation
  13860. problem.  It is suppose to, however, report an error if far memory is
  13861. requested and far memory is not available.  Previously, if far memory was
  13862. not available and near memory was, no error was reported.  I have not
  13863. tested this personally, it isfrom a review that I read.  It was changed to
  13864. conform to the new ANSI standard.
  13865. Ron
  13866. ---------------
  13867. ** Current thread: MICROSCHLOCK C
  13868.  
  13869. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35E23555 Date: 05/10/90
  13870. From: RON FOX                                               Time: 02:59 am
  13871.   To: ALL                                                   (Read 72 times)
  13872. Subj: MICROSCHLOCK C
  13873.  
  13874. I did some checking with MSC version 6.0 regarding the release of freed
  13875. memory back to the operating system and found that Microsoft did not fix
  13876. the malloc bug.  During testing, I found memory shrinking in 8K chunks.
  13877. Microsoft added two functions to its' library as a "fix".  The functions
  13878. are _heapmin and _fheapmin to release heap and specifically far heap back
  13879. to the operating system.  I have tried _heapmin and it seems to work.  At
  13880. least in the two instances that caused memory fragmentation that I was
  13881. working on.  It seems a "kludge" instead of a real fix.
  13882. Ron
  13883. ---------------
  13884. ** Current thread: MICROSCHLOCK C
  13885.  
  13886. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35EH2241 Date: 05/10/90
  13887. From: THOMAS ZERUCHA                                        Time: 01:37 pm
  13888.   To: GRANT ELLSWORTH (Rcvd)                                (Read 74 times)
  13889. Subj: R: MICROSCHLOCK C
  13890.  
  13891. (Walla Walla C - I will have to remember that)  I just saw the Ads and
  13892. reviews in Doctor Dobbs Journal, and called their BBS where they have
  13893. all the patches to fix bugs, and the tech support actually does respond
  13894. and know the answers!  Supposedly they sent upgrade notices, but the
  13895. compiler won't be released until June (the 386 Native mode should be
  13896. out about right now), they may have been discussing the policy and
  13897. prices for the upgrades.  There will be Three variants of 8.0, A 386
  13898. Native mode that breaks 640K, A "professional" version of *86 with a
  13899. 386 version of the compiler (faster and no Insufficent Memory to Optimize
  13900. messages), and a "personal" version that has no version that runs in
  13901. 386 and may exclude a few extras.  I will try to find the description
  13902. files and upload them.
  13903.      After Microsoft, Watcom is "awsome", but I have used VAX C (not for
  13904. ports) which does all kinds of mainframe level optimizations.  Watcom 7.0
  13905. is really close, 8.0 should be there.
  13906.      Also, (from DDJ article) Watcom should support the next version of
  13907. Turbo Debugger (Borland published the specs).
  13908. .
  13909. ---------------
  13910. ** Current thread: MICROSCHLOCK C
  13911.  
  13912. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35EN2736 Date: 05/10/90
  13913. From: ROBERT BALSOVER                                       Time: 07:45 pm
  13914.   To: GRANT ELLSWORTH (Rcvd)                                (Read 72 times)
  13915. Subj: R: MICROSCHLOCK C
  13916.  
  13917. Grant,
  13918.      I read somewhere that Paradox 386 was written in Watcom C.  In fact,
  13919. the way the article sounded, Borland was promoting someone elses compiler.
  13920. Do you suppose this is a sign that Borland is in no real hurry to produce
  13921. their own 386 C compiler?
  13922.      Have you heard about the InfoWorld articles mention of TC 3.0?  They
  13923. said Borland will make a announcement May 14.  From what I heard of it, I
  13924. don't know if I'm going to like it.   I hope its just rumors.
  13925. Bob
  13926. ---------------
  13927. ** Current thread: MICROSCHLOCK C
  13928.  
  13929. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35ES2570 Date: 05/10/90
  13930. From: GRANT ELLSWORTH (Leader)                              Time: 11:42 pm
  13931.   To: RON FOX (Rcvd)                                        (Read 71 times)
  13932. Subj: R: MICROSCHLOCK C
  13933.  
  13934. Ron, Watcom claims 100% compatibility with M$C.  But, my experience with
  13935. WC 6.5 and 7.0 suggest there will be a few minor (very minor) snags.
  13936. Unlike TC, WC uses the same function names for the low_level dos calls,
  13937. which simplifies the "translation".
  13938.  
  13939. On memory fragmentation:  I understand that M$C6.0 does no better than its
  13940. predecessors in avoiding it.  The near/far resolution you described may
  13941. work, but one writer I read commented "unfavorably" on the fix --- I don't
  13942. remember the details.
  13943.  
  13944. WC7.0 just didn't seem to fragment memeory a la m$c.  Whether or not it
  13945. just defers the effect or has an effective "garbage collector", I can not
  13946. say.  I don't remember any reviews of any WC (6.0, 6.5,7.0) commenting
  13947. that there was a problem in this area.
  13948.  
  13949. BTW: I DID stumble into a very NASTY bug in WC6.5 which went unfixed in
  13950. 7.0 --- even after I called it in:  a function call to an interrupt
  13951. routine with return expected was not generating the right code --- the
  13952. compiler forgot to push() the flags!  I was able to use a #pragma to gen
  13953. the necessary PUSHF instruction ... but that is SO ugly.  Hopefully, the
  13954. Waterloo gang has fixed that nasty in 8.0.  Grant
  13955. ---------------
  13956. ** Current thread: MICROSCHLOCK C
  13957.  
  13958. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35ES2861 Date: 05/10/90
  13959. From: GRANT ELLSWORTH (Leader)                              Time: 11:47 pm
  13960.   To: THOMAS ZERUCHA (Rcvd)                                 (Read 73 times)
  13961. Subj: R: MICROSCHLOCK C
  13962.  
  13963. If Watcom 8.0 can work with the Turbo debugger (even if it is the next
  13964. version), then the Wallapoleon gang will definitely have met their Water-
  13965. loo!  Looking forward to your upload.     Leave msg here advising on file
  13966. name when//if you find the info!  Grant
  13967. ---------------
  13968. ** Current thread: MICROSCHLOCK C
  13969.  
  13970. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35ES3331 Date: 05/10/90
  13971. From: GRANT ELLSWORTH (Leader)                              Time: 11:55 pm
  13972.   To: ROBERT BALSOVER (Rcvd)                                (Read 70 times)
  13973. Subj: R: MICROSCHLOCK C
  13974.  
  13975. I frequent the Borland Forum on CI$.  I have not seen anything confirming
  13976. an upcoming announcement of any kind.     The only thing I infer from the
  13977. trade press and the stuff not said is that TC3.0 will NOT provide a C++
  13978. option.  Rumors reported in the trade press suggest that Borland will
  13979. offer C++ as a separate package at some later date.  From what I've seen,
  13980. the C++ support is the biggest demand --- ergo, the client base will have
  13981. no reason to be thrilled.  Contrary to the stuff you cited, I have a junch
  13982. that TC3.0 will have a 386 option --- placating some, but not all.
  13983.  
  13984. For my part, I'd prefer the C++ option.  Looks generically more useful in
  13985. the long term.  By the time any recent 386-based compiler is really solid
  13986. and proven in the applications, we'll all be screaming for the 80686 ex-
  13987. ploiting version.  grant
  13988. ---------------
  13989. ** Current thread: MICROSCHLOCK C
  13990.  
  13991. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35F10280 Date: 05/11/90
  13992. From: GRANT ELLSWORTH (Leader)                              Time: 12:04 am
  13993.   To: RON FOX (Rcvd)                                        (Read 72 times)
  13994. Subj: R: MICROSCHLOCK C
  13995.  
  13996. That solution is not a kludge ,.,, it is unconcienable slop. Grant
  13997. ---------------
  13998. ** Current thread: MICROSCHLOCK C
  13999.  
  14000. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35FD1275 Date: 05/11/90
  14001. From: THOMAS ZERUCHA                                        Time: 09:21 am
  14002.   To: GRANT ELLSWORTH (Rcvd)                                (Read 72 times)
  14003. Subj: R: MICROSCHLOCK C
  14004.  
  14005. WATC80PI.ZIP - WATcom C 8.0 Product Information.  In Mahoney.
  14006. Has two files, one on the 386 compiler, one on the "286" compiler.
  14007. ---------------
  14008. ** Current thread: MICROSCHLOCK C
  14009.  
  14010. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35FI1382 Date: 05/11/90
  14011. From: TOM FELLER                                            Time: 02:23 pm
  14012.   To: THOMAS ZERUCHA (Rcvd)                                 (Read 72 times)
  14013. Subj: R: MICROSCHLOCK C
  14014.  
  14015. Thanks, can you please give me the volume of the DDJ that has that fix.
  14016. I do get DDJ but I don't recall that article.
  14017. \Tom Feller\
  14018. ---------------
  14019. ** Current thread: MICROSCHLOCK C
  14020.  
  14021. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35FP1308 Date: 05/11/90
  14022. From: ROBERT BALSOVER                                       Time: 08:21 pm
  14023.   To: GRANT ELLSWORTH (Rcvd)                                (Read 72 times)
  14024. Subj: R: MICROSCHLOCK C
  14025.  
  14026. I dunno, Making the C++ option a *additional* upgrade reminds me of MSC
  14027. 5.0 and 5.1.  Didn't you have to upgrade to 5.1 to get OS/2 support?
  14028. If Borland starts imitating MS, I'll start looking at someone elses
  14029. products. Maybe JPL, I heard that their C compiler is the original Turbo
  14030. C.
  14031. Bob
  14032. ---------------
  14033. ** Current thread: MICROSCHLOCK C
  14034.  
  14035. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35FP1566 Date: 05/11/90
  14036. From: GRANT ELLSWORTH (Leader)                              Time: 08:26 pm
  14037.   To: THOMAS ZERUCHA (Rcvd)                                 (Read 71 times)
  14038. Subj: R: MICROSCHLOCK C
  14039.  
  14040. Thanks a bunch.  Grant
  14041. ---------------
  14042. ** Current thread: MICROSCHLOCK C
  14043.  
  14044. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35FP1840 Date: 05/11/90
  14045. From: GRANT ELLSWORTH (Leader)                              Time: 08:30 pm
  14046.   To: ROBERT BALSOVER (Rcvd)                                (Read 73 times)
  14047. Subj: R: MICROSCHLOCK C
  14048.  
  14049. I don't think C++ in TC is quite the same as M$C 5.0 --> 5.1 for OS/2 cap=
  14050. ability.  Borland would have to sink a long way to imitate MS --- they'd
  14051. have to start releasing really sloppy stuff and call it an "upgrade". Then
  14052. they'd have to call the bug-fix release to the upgrade a "Major Release".
  14053.  
  14054. ---------------
  14055. ** Current thread: MICROSCHLOCK C
  14056.  
  14057. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35FQ1472 Date: 05/11/90
  14058. From: RON FOX                                               Time: 09:24 pm
  14059.   To: GRANT ELLSWORTH (Rcvd)                                (Read 73 times)
  14060. Subj: R: MICROSCHLOCK C
  14061.  
  14062. Agreed!!!
  14063. Ron
  14064. ---------------
  14065. ** Current thread: MICROSCHLOCK C
  14066.  
  14067. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35GF1800 Date: 05/12/90
  14068. From: ROBERT BALSOVER                                       Time: 11:30 am
  14069.   To: GRANT ELLSWORTH (Rcvd)                                (Read 76 times)
  14070. Subj: R: MICROSCHLOCK C
  14071.  
  14072. Grant,
  14073. I have to disagree with you.  We're not talking about bugs (no contest),
  14074. we're talking about the addition of C++.  C++ is a superset of C, right?
  14075. If they release the TC3.0 first, then release TC++ after that time, most
  14076. people will upgrade to the normal C, then have to do it again for C++
  14077. shortly after that. That is what I'm talking about when I refer to MSC 5.0
  14078. & 5.1.
  14079. Bob
  14080. P.S. yes I know Zortech does it, but I don't own their stuff.
  14081. ---------------
  14082. ** Current thread: MICROSCHLOCK C
  14083.  
  14084. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35H12395 Date: 05/13/90
  14085. From: RICHARD POELING                                       Time: 01:39 am
  14086.   To: THOMAS ZERUCHA (Rcvd)                                 (Read 78 times)
  14087. Subj: R: MICROSCHLOCK C
  14088.  
  14089. What kind of debugging tools come with Watcom?  Is debugging with Watcom
  14090. very easy?
  14091. ---------------
  14092. ** Current thread: MICROSCHLOCK C
  14093.  
  14094. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35HE2593 Date: 05/13/90
  14095. From: ROBERT BALSOVER                                       Time: 10:43 am
  14096.   To: RICHARD POELING (Rcvd)                                (Read 73 times)
  14097. Subj: R: MICROSCHLOCK C
  14098.  
  14099. Richard,
  14100.      I've heard that Watcom will support Turbo Debugger soon, maybe in the
  14101. upcoming release.  Borland released the specs for its debugging info.
  14102. Bob
  14103. ---------------
  14104. ** Current thread: MICROSCHLOCK C
  14105.  
  14106. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35IM1379 Date: 05/14/90
  14107. From: GRANT ELLSWORTH (Leader)                              Time: 06:23 pm
  14108.   To: ROBERT BALSOVER (Rcvd)                                (Read 73 times)
  14109. Subj: R: MICROSCHLOCK C
  14110.  
  14111. Bob, I gave the matter some thought .. I just can't equate c++ support in
  14112. TC with o/s2 support in M$C.  The situations are similar.  And any squawk-
  14113. I would do would depend entirely on the cost of the  upgrade.  I don't
  14114. object to paying something extra for c++ within TC; I view c++ as an
  14115. additional language.  On os/2 in m$C, I think the upgrade $$ conceptually
  14116. was justified.  But MS's attitude towards the quality of the C product
  14117. undermines any positive consideration I would give them.  The bugs and
  14118. constraints in the M$C product are alarming.  Grant
  14119. ---------------
  14120. ** Current thread: MICROSCHLOCK C
  14121.  
  14122. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35IM1984 Date: 05/14/90
  14123. From: GRANT ELLSWORTH (Leader)                              Time: 06:33 pm
  14124.   To: RICHARD POELING (Rcvd)                                (Read 70 times)
  14125. Subj: R: MICROSCHLOCK C
  14126.  
  14127. As of release 7.0, Watcom C included a debugger WVIDEO.  As a debugger,
  14128. it's about halfway between M$C's CodeView and Borland's Turbo Debugger.
  14129. I found Wvideo flexible, but a little clumsy to use.  Grant
  14130. ---------------
  14131. ** Current thread: MICROSCHLOCK C
  14132.  
  14133. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35IR0303 Date: 05/14/90
  14134. From: ROBERT BALSOVER                                       Time: 10:05 pm
  14135.   To: GRANT ELLSWORTH (Rcvd)                                (Read 71 times)
  14136. Subj: R: MICROSCHLOCK C
  14137.  
  14138. Grant,
  14139. It amazes me sometimes when I see the loyalty people have to their
  14140. compiler of choice.  I am happy with TC, I was just reacting to a
  14141. InfoWorld article.  Today, Borland announced TC++ 3.0.  It is not two
  14142. products, only one.  It no longer matters what InfoWorld, they can't make
  14143. anymore money on that speculation.  I'm glad I don't subscribe to them.
  14144. Bob
  14145. ---------------
  14146. ** Current thread: MICROSCHLOCK C
  14147.  
  14148. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35IR0668 Date: 05/14/90
  14149. From: GRANT ELLSWORTH (Leader)                              Time: 10:11 pm
  14150.   To: ROBERT BALSOVER (Rcvd)                                (Read 71 times)
  14151. Subj: R: MICROSCHLOCK C
  14152.  
  14153. Bob, I haven't read InfoWorld much since 1984.  The trade press has 2
  14154. unfortunate habits: 1.  If IBM. M$, Lotus speak --- it's gospel.  2.
  14155. If it makes (NOT)(IBM, MS, Lotus) look bad (or greedy), it's just gotta
  14156. be true.
  14157.  
  14158. Lest I forget, the Trade Press is the greatest rumor mill since last cen-
  14159. tury's back fence.  Grant
  14160. ---------------
  14161. ** Current thread: MICROSCHLOCK C
  14162.  
  14163. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35IR2170 Date: 05/14/90
  14164. From: ROBERT BALSOVER                                       Time: 10:36 pm
  14165.   To: GRANT ELLSWORTH (Rcvd)                                (Read 72 times)
  14166. Subj: R: MICROSCHLOCK C
  14167.  
  14168. Grant,
  14169.     I was not 100% correct, I just read the messages on CIS.  There are
  14170. two C compilers from Borland.  TC 2.0 will continue to exist.  The good
  14171. part is that Borland is taking orders and shipping *today*.  They are also
  14172. shipping Turbo Profiler *today*.
  14173. Bob
  14174. Ps I have uploaded two files to the IBM DL area, written in TC++.
  14175. serial.zip and new.zip.  I got them from CIS.
  14176. ---------------
  14177. ** Current thread: MICROSCHLOCK C
  14178.  
  14179. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35JP2794 Date: 05/15/90
  14180. From: THOMAS ZERUCHA                                        Time: 08:46 pm
  14181.   To: TOM FELLER                                            (Read 73 times)
  14182. Subj: R: MICROSCHLOCK C
  14183.  
  14184. I don't remember exactly, but I think it was Nov '89.  Source is here
  14185. DDJmmyy.zip in Mahoney.  I will look further (but Watcom arrived just as
  14186. we were trying this hack so it fell by the wayside).
  14187. ---------------
  14188. ** Current thread: MICROSCHLOCK C
  14189.  
  14190. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35JP3178 Date: 05/15/90
  14191. From: THOMAS ZERUCHA                                        Time: 08:52 pm
  14192.   To: RICHARD POELING (Rcvd)                                (Read 73 times)
  14193. Subj: R: MICROSCHLOCK C
  14194.  
  14195. Watcom C has a screen debugger (even a remote mode like Turbo), but our
  14196. application made such difficult.  It can't loadhi like the 386 Turbo
  14197. debug or Codeview (this may change).  You have to reduce optimization to
  14198. do debugging (since source lines tend to disappear or merge as do
  14199. variables that disappear into registers).  I haven't found it any worse
  14200. than Microsoft, but I rarely use the supplied debuggers (except with
  14201. Power C which is really easy and displays everything I want easily).
  14202. So I am not really a good judge of debuggers, but from what I have done it
  14203. seems usable.
  14204. ---------------
  14205. ** Current thread: MICROSCHLOCK C
  14206.  
  14207. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35JP3229 Date: 05/15/90
  14208. From: GRANT ELLSWORTH (Leader)                              Time: 08:53 pm
  14209.   To: ROBERT BALSOVER (Rcvd)                                (Read 72 times)
  14210. Subj: R: MICROSCHLOCK C
  14211.  
  14212. Thanks very much for sharing the info with us.  From what BI says, I con-
  14213. clude that TC++ is one heck of a product.  My order is going out as soon
  14214. as I can get it to a mailbox.  Grant
  14215. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  14216.  
  14217. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 355L2326 Date: 05/05/90
  14218. From: TOM FELLER                                            Time: 05:38 pm
  14219.   To: ALL                                                   (Read 71 times)
  14220. Subj: PC-LAN 1.3
  14221.  
  14222. Warning: Bug found in PC-LAN 1.3 and may be in other versions.
  14223. The system will lock if you try to find the attributes of a file related
  14224. to the printer like like LPT1. It's a standard MS-DOS function int 21 with
  14225. 43 function and file name of LPT1. It will lock the system. This bug was
  14226. found because Turbo C uses this in it's fopen function. The internal
  14227. Turbo C function in fopen is _chmod(). Just try it, it will lock PC-LAN
  14228. 1.3  and it works fine under MS-DOS.
  14229. Tom Feller
  14230. ---------------
  14231.  
  14232. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 355L3572 Date: 05/05/90
  14233. From: JONATHAN CROCKETT                                     Time: 05:59 pm
  14234.   To: ALL                                                   (Read 72 times)
  14235. Subj: BUSPERF
  14236.  
  14237. Hello,
  14238. I recently found a program in Mahoney called 'busperf.exe', that came from
  14239. a 1986 or early 87 PC Tech Journal. Unfortunately, the source for this
  14240. program (C) is not on this board, and no local libraries carry PC Tech
  14241. Journal, This source could be very important to a project I'm working on
  14242. it and I would much appreciate it if  someone who has a library of PCTJ
  14243. stuff could look it up for me and tell me exactly which issue it came
  14244. from, and upload the source. Thanx.
  14245.  
  14246. Jonathan Crockett
  14247. ---------------
  14248. Following thread
  14249.  
  14250. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35AQ0720 Date: 05/06/90
  14251. From: GLEN THOMPSON                                         Time: 09:12 pm
  14252.   To: JONATHAN CROCKETT (Rcvd)                              (Read 70 times)
  14253. Subj: R: BUSPERF
  14254.  
  14255. Jonathan,
  14256.  
  14257. Looking in the 1987 Index shows nothing about a program named busperf.
  14258. Do you have any more information on the name of the article?  I've got an
  14259. almost complete set of PCTJ so I probably have the article.  Give me
  14260. whatever other information you have.
  14261.  
  14262. glen
  14263. ---------------
  14264. ** Current thread: BUSPERF
  14265.  
  14266. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35AS2735 Date: 05/06/90
  14267. From: JONATHAN CROCKETT                                     Time: 11:45 pm
  14268.   To: GLEN THOMPSON (Rcvd)                                  (Read 74 times)
  14269. Subj: R: BUSPERF
  14270.  
  14271. Glen,
  14272.  
  14273. The only information I have on the program is from the program itself.
  14274. When it runs it displays a title that says copyright PC Tech Journal 1986.
  14275. I scanned through the file busperf.exe with Norton's Utility and found a C
  14276. parameter string used by printf, which is how I know it's written in C.
  14277. The file busperf.zip containing busperf.exe is in the Mahoney collection
  14278. and is about 9k. Thanx for your response.
  14279.  
  14280. Jonathan.
  14281. ---------------
  14282. ** Current thread: BUSPERF
  14283.  
  14284. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35CQ0613 Date: 05/08/90
  14285. From: GLEN THOMPSON                                         Time: 09:10 pm
  14286.   To: JONATHAN CROCKETT (Rcvd)                              (Read 67 times)
  14287. Subj: R: BUSPERF
  14288.  
  14289. ---------------
  14290. ** Current thread: BUSPERF
  14291.  
  14292. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35DR2656 Date: 05/09/90
  14293. From: RON FOX                                               Time: 10:44 pm
  14294.   To: JONATHAN CROCKETT (Rcvd)                              (Read 68 times)
  14295. Subj: R: BUSPERF
  14296.  
  14297. John,
  14298. I looked through the PC TECH issues from August 1986 and could not find a
  14299. BUSPERF program.  There are, however, several other AT preformance
  14300. programs listed.  ATBIOS, ATPERF, ATFLOAT, ATDISK are some of them.  I
  14301. believe that they can be downloaded from this bulliten board but I cannot
  14302. remember the filename.  If you need the source of any of these, the issue
  14303. is PC TECH, August 1986 pages 60-.  I would copy the relevant pages and
  14304. send them to you.  But I cannot type them in as it would take me at least
  14305. a week.  I am a pretty poor typer.
  14306. Ron
  14307. ---------------
  14308. ** Current thread: BUSPERF
  14309.  
  14310. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35F21330 Date: 05/11/90
  14311. From: JONATHAN CROCKETT                                     Time: 02:22 am
  14312.   To: RON FOX (Rcvd)                                        (Read 69 times)
  14313. Subj: R: BUSPERF
  14314.  
  14315. Ron,
  14316. I have ATBIOS, ATPERF, etc including the source I downloaded from this
  14317. BBS. My only clue to finding the source to busperf is the copyright
  14318. message the program displays when I run it that says (C) 1986.
  14319.  
  14320. Jonathan
  14321. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  14322.  
  14323. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 355M0156 Date: 05/05/90
  14324. From: JONATHAN CROCKETT                                     Time: 06:02 pm
  14325.   To: ALL                                                   (Read 71 times)
  14326. Subj: INTEL CHIPS REF
  14327.  
  14328. Hello,
  14329. I am looking for a good reference to Intel support chips such as the 8253
  14330. timer, 8259, 8255, 8254, etc. Can anyone help?
  14331. ---------------
  14332.  
  14333. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35C30702 Date: 05/08/90
  14334. From: AMINUDDIN AHMAD                                       Time: 03:11 am
  14335.   To: ALL                                                   (Read 74 times)
  14336. Subj: ALT-CTRL-DEL
  14337.  
  14338. I need some help. Anybody knows how to disable alt-ctrl-del (reboot) in
  14339. Turbo C? I've looked in the manual but can't seems to find it. Maybe
  14340. because I dont really know where to find it. Thanks in advance.
  14341.  
  14342. --->Amin.
  14343. ---------------
  14344. Following thread
  14345.  
  14346. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35DC0367 Date: 05/09/90
  14347. From: STEVEN KEY                                            Time: 08:06 am
  14348.   To: AMINUDDIN AHMAD (Rcvd)                                (Read 72 times)
  14349. Subj: R: ALT-CTRL-DEL
  14350.  
  14351. Amin,
  14352.  
  14353. I'm not a C'er, so I don't know if TC has a built in way to disable
  14354. Ctrl-Alt_Del, but I know Turbo Pascal does not.  Ctrl-Alt-Del is built in
  14355. to the ROM BIOS.  There are some TSR programs that will disable the
  14356. function for you.  Do a search in the Mahoney file collection for
  14357. Ctrl_alt_del.  You may need to look for things like "disable" and "TSR".
  14358.  
  14359. Steven
  14360. ---------------
  14361. ** Current thread: ALT-CTRL-DEL
  14362.  
  14363. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35DI2187 Date: 05/09/90
  14364. From: AMINUDDIN AHMAD                                       Time: 02:36 pm
  14365.   To: STEVEN KEY (Rcvd)                                     (Read 70 times)
  14366. Subj: R: ALT-CTRL-DEL
  14367.  
  14368. I'll try. Thanks anyway..
  14369.  
  14370. --->Amin.
  14371. ---------------
  14372. ** Current thread: ALT-CTRL-DEL
  14373.  
  14374. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35DR2106 Date: 05/09/90
  14375. From: RON FOX                                               Time: 10:35 pm
  14376.   To: AMINUDDIN AHMAD (Rcvd)                                (Read 72 times)
  14377. Subj: R: ALT-CTRL-DEL
  14378.  
  14379. Amin,
  14380. About a year ago, July 1989, there were a number of messages refereing to
  14381. the CTRL-C and CTRL-BREAK by-passing routines discussed.  One of the
  14382. programs that I have modified was CARTOC.  I modified the interrupt far
  14383. Int09 routine.   if (BITSET(*KbdCtrl, 2) && ((LOBYTE(inp(0x60)) == 53) ||
  14384. (LOBYTE(inp(0x60))==0x2E) || (LOBYTE(inp(0x60))==0x03)))  replaces
  14385. This looks for the CTRL-C, CTRL-@, and CTRL-ALT key sequences.
  14386. This works, although it is a bit dirty, in MSC 5.0, 5.1 and 6.0.  I don't
  14387. know if it will work in Turbo.
  14388. Hope that it is of some help though.
  14389. Ron
  14390. ---------------
  14391. ** Current thread: ALT-CTRL-DEL
  14392.  
  14393. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35EM2010 Date: 05/10/90
  14394. From: AMINUDDIN AHMAD                                       Time: 06:33 pm
  14395.   To: RON FOX (Rcvd)                                        (Read 69 times)
  14396. Subj: R: ALT-CTRL-DEL
  14397.  
  14398. Thanks, I'll give it a shot. You dont happen to know how to disable
  14399. alt-ctrl-del do you?
  14400.  
  14401. --->Amin.
  14402. ---------------
  14403. ** Current thread: ALT-CTRL-DEL
  14404.  
  14405. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35F10123 Date: 05/11/90
  14406. From: GRANT ELLSWORTH (Leader)                              Time: 12:02 am
  14407.   To: RON FOX (Rcvd)                                        (Read 71 times)
  14408. Subj: R: ALT-CTRL-DEL
  14409.  
  14410. Ron, I uploaded a ZIP a couple of months ago with a ^C, ^@ (the stinker),
  14411. and ^brk trap --- called "getkbd.zip", if I remember right.  I finished it
  14412. sometime shortly after the 1st round robin we had here in 88 and forgot to
  14413. put it out for the public.  Yes, the carotc baseline can work in TC, and ,
  14414. with one major mod (covering for a bug in it), in Watcom C.  All the
  14415. routines I submitted would work in M$C, TC, and WC (thru 7.0).   Grant
  14416. ---------------
  14417. ** Current thread: ALT-CTRL-DEL
  14418.  
  14419. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35FQ1424 Date: 05/11/90
  14420. From: RON FOX                                               Time: 09:23 pm
  14421.   To: GRANT ELLSWORTH (Rcvd)                                (Read 72 times)
  14422. Subj: R: ALT-CTRL-DEL
  14423.  
  14424. Grant
  14425. Thanks, I will look at "getkbd.zip"
  14426. Ron
  14427. ---------------
  14428. ** Current thread: ALT-CTRL-DEL
  14429.  
  14430. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35HN0689 Date: 05/13/90
  14431. From: JEFF NOWLAND                                          Time: 07:11 pm
  14432.   To: AMINUDDIN AHMAD (Rcvd)                                (Read 77 times)
  14433. Subj: R: ALT-CTRL-DEL
  14434.  
  14435. Amin,
  14436. By hooking the INT 19h vector you can disable alt-ctrl-del.  When the
  14437. keyboard detects this combination, it calls that interrupt after poking a
  14438. 1234h into some memory location(I don't remember which) telling the int
  14439. 19h routine to perform the "warm" boot. In TC if you only wish to disable
  14440. then it should be sufficient to:
  14441. void interrupt my_boot_disabled( void ) { }
  14442. int main( int args, char *argv[] )
  14443. {
  14444. void interrupt (*old19)();
  14445.   old19 = getvect( 0x19 );
  14446.   setvect( 0x19, my_boot_disabled );
  14447.   do_your_stuff();
  14448.   setvect( 0x19, old19 );
  14449.   exit( code );
  14450. }
  14451. I think this might be simpler than looking for a key sequence in the
  14452. keyboard interrupt.
  14453. JDNowland.
  14454. ---------------
  14455. ** Current thread: ALT-CTRL-DEL
  14456.  
  14457. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35HS2477 Date: 05/13/90
  14458. From: AMINUDDIN AHMAD                                       Time: 11:41 pm
  14459.   To: JEFF NOWLAND (Rcvd)                                   (Read 71 times)
  14460. Subj: R: ALT-CTRL-DEL
  14461.  
  14462. Thanks......  I really need that.
  14463.  
  14464. --->Amin.
  14465. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  14466.  
  14467. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35JQ0162 Date: 05/15/90
  14468. From: LARRY BRADSHAW                                        Time: 09:02 pm
  14469.   To: GRANT ELLSWORTH (Rcvd)                                (Read 76 times)
  14470. Subj: TC++ FOR TC PRO &
  14471.  
  14472. I am considering purchasing the TC++ for my TurboC-Pro. If anybody has it,
  14473. can you please tell me of it's characteristics...Intended use is for appl.
  14474. dev. w/the Paradox Engine....  which  I also own..
  14475.  
  14476. May integrate with some net apps & Q-Pro as well. We'll see.
  14477.  
  14478. Anyway, any info is appreciated. Consider me an educated novice and we
  14479. will no doubt be able to communicate on the first go. As I understand it,
  14480. for $78, it's a must-buy.... No problem, but knowing what to expect would
  14481. be nice.
  14482.  
  14483. I either have to triple my time spent programming or acquire a code
  14484. generator like Matrix. Any feedback on that would also be very
  14485. appreciated.
  14486.  
  14487. Larry
  14488. ---------------
  14489. Following thread
  14490.  
  14491. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35KS0538 Date: 05/16/90
  14492. From: GRANT ELLSWORTH (Leader)                              Time: 11:08 pm
  14493.   To: LARRY BRADSHAW (Rcvd)                                 (Read 74 times)
  14494. Subj: R: TC++ FOR TC PRO &
  14495.  
  14496. Larry, I expect that TC++ is as usable in conjunction with Pardox as TC
  14497. 2.0 ... especially if the "C" subset of TC++ is used.  However, I don't
  14498. have any notion as to how helpful TC++ will be to you as a coding shortcut
  14499. as you might find other packages.  Otherwise, on TC++ itself, I don
  14500. t think we'll be seeing any detailed commentary until somebody here has
  14501. a copy on-hand and has had the time to work with it a bit.  BI just
  14502. started shipping it this week --- with advisement that orders will take up
  14503. to 4 weeks to fulfil.   Grant
  14504. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  14505.  
  14506. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35JQ2019 Date: 05/15/90
  14507. From: MARTY GSCHEIDMEIER                                    Time: 09:33 pm
  14508.   To: ALL                                                   (Read 69 times)
  14509. Subj: C TUTORIALS
  14510.  
  14511.        I would like to start learning programming in C language
  14512. and was hoping someone could recommend a good tutorial for the
  14513. complete novice? A book or list of books that would give me a
  14514. good start.
  14515.        Is any particular software package better documented in
  14516. respect to the novice?
  14517.                                   Thanks
  14518.                                           Marty
  14519. ---------------
  14520. Following thread
  14521.  
  14522. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35KQ0283 Date: 05/16/90
  14523. From: MARTY GSCHEIDMEIER                                    Time: 09:04 pm
  14524.   To: NESHAM SOFTWARE (Rcvd)                                (Read 73 times)
  14525. Subj: R: C TUTORIALS
  14526.  
  14527.      Thanks Tim,
  14528.     I'll look into it.
  14529.  
  14530.  Marty
  14531. ---------------
  14532. ** Current thread: C TUTORIALS
  14533.  
  14534. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35KR1482 Date: 05/16/90
  14535. From: JIM MONROE                                            Time: 10:24 pm
  14536.   To: MARTY GSCHEIDMEIER (Rcvd)                             (Read 67 times)
  14537. Subj: R: C TUTORIALS
  14538.  
  14539. I have been using the Power c from MIX, it is super, the book is worth the
  14540. price. The latest version uses varied memorary models so it is quite
  14541. compatable with the rest of the world. If you like, there are a number of
  14542. folks at the IBM PC users group that are into C. would like to meet more
  14543. folks with the same interests "C" and programing in general.
  14544. //
  14545. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  14546.  
  14547. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35KN2834 Date: 05/16/90
  14548. From: JEFF NOWLAND                                          Time: 07:47 pm
  14549.   To: ALL                                                   (Read 72 times)
  14550. Subj: MEMORY ALLOCATION
  14551.  
  14552. Does anyone know what happens to a memory block if an attempt to realloc
  14553. it fails.  I've seen some code examples that indicated that the original
  14554. block is still a valid pointer(ie. still part of the allocated pool).  At
  14555. first I thought it might be a programming error, but there were comments
  14556. to the effect that the programmer expected the original block to still be
  14557. good.  The TC manual doesn't say anything about this, and it becomes an
  14558. important question when attempting to create a memory protecting shceme
  14559. for some of my projects.  Any help would be appreciated.
  14560. JDNowland.
  14561. ---------------
  14562. Following thread
  14563.  
  14564. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35KR1590 Date: 05/16/90
  14565. From: JIM MONROE                                            Time: 10:26 pm
  14566.   To: JEFF NOWLAND (Rcvd)                                   (Read 70 times)
  14567. Subj: R: MEMORY ALLOCATION
  14568.  
  14569. I have never seen info on this topic but would be interested in finding
  14570. out. Please share any replies that you receive.
  14571. ---------------
  14572. ** Current thread: MEMORY ALLOCATION
  14573.  
  14574. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35LB1275 Date: 05/17/90
  14575. From: STEVEN KEY                                            Time: 07:21 am
  14576.   To: JEFF NOWLAND (Rcvd)                                   (Read 73 times)
  14577. Subj: R: MEMORY ALLOCATION
  14578.  
  14579. Jeff,
  14580.  
  14581. I don't C, so I can't say how TC might work, but the info in Ray Duncan's
  14582. Advanced MSDOS does not indicate that a block is deallocated if a resize
  14583. request fails.  It appears that at the DOS level at least, an explicit
  14584. release memory call would have to be made to get rid of a block.  The DOS
  14585. resize function returns BX with the maximum number of paragraphs available
  14586. if the function fails.
  14587.  
  14588. Steven
  14589. ---------------
  14590. ** Current thread: MEMORY ALLOCATION
  14591.  
  14592. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35NJ2013 Date: 05/19/90
  14593. From: JEFF NOWLAND                                          Time: 03:33 pm
  14594.   To: STEVEN KEY (Rcvd)                                     (Read 72 times)
  14595. Subj: R: MEMORY ALLOCATION
  14596.  
  14597. Steve,
  14598. As TC is now releasing their new product(TC++), I had cause to give them a
  14599. ring anyway.  Their tech guy said I could assume the block is there.  I
  14600. also debugged the code for the realloc function and found another
  14601. disturbing thing.  When you realloc, not only is there a possibility of
  14602. the blocks address changing, it has to change.  realloc calls farrealloc
  14603. which calls farmalloc to allocate a new block, then copies the old info to
  14604. the new block.  Given that TC keeps the block size info in an area just
  14605. below the allocation along with linkage to other blocks, I assumed it
  14606. would first attempt to simply increase the size of that block. To make a
  14607. long story short, if you have a 60K block of memory and you want to make
  14608. it 61K, you better have at least 61K of free memory(besides the block
  14609. being realloced).
  14610. Thanks for the help!
  14611. JDNowland.
  14612. ---------------
  14613. ** Current thread: MEMORY ALLOCATION
  14614.  
  14615. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35NJ2254 Date: 05/19/90
  14616. From: JEFF NOWLAND                                          Time: 03:37 pm
  14617.   To: JIM MONROE (Rcvd)                                     (Read 73 times)
  14618. Subj: R: MEMORY ALLOCATION
  14619.  
  14620. Jim,
  14621. Thanks for the reply, see my reply to Steven Key.  I was a little
  14622. disappointed to see how TC actually implements its realloc function.  It
  14623. does no more than what you or I might do if we wanted a larger block of
  14624. memory, namely, malloc the new block and copy the old info.  The
  14625. documentation says that the address of the block might change when
  14626. reallocting memory, looking at their code, it will either change the
  14627. location or fail.
  14628. JDNowland.
  14629. ---------------
  14630. ** Current thread: MEMORY ALLOCATION
  14631.  
  14632. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35UP3016 Date: 05/25/90
  14633. From: JIM MONROE                                            Time: 08:50 pm
  14634.   To: JEFF NOWLAND (Rcvd)                                   (Read 77 times)
  14635. Subj: R: MEMORY ALLOCATION
  14636.  
  14637. While tc is very popular I wonder how many other little in adequacies they
  14638. have in the code. I do not have TC so my knowledge is only hear say. I use
  14639. MIX and are quite happy so far.  There recently was some articles in
  14640. either Dr Dobbs or C Users Journal about memorary allocation. I will see
  14641. if I can find them and get back to you.
  14642. ---------------
  14643. ** Current thread: MEMORY ALLOCATION
  14644.  
  14645. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35WI2989 Date: 05/27/90
  14646. From: JEFF NOWLAND                                          Time: 02:49 pm
  14647.   To: JIM MONROE (Rcvd)                                     (Read 75 times)
  14648. Subj: R: MEMORY ALLOCATION
  14649.  
  14650. Thanx, I'm interested in what they may have to say.  In the meanwhile, I
  14651. am pleased that reallocation doesn't destroy data on failure, it makes
  14652. error recovery much simpler on out of memory schemes.  I've always been
  14653. annoyed with programs that run out of memory then anounce this fact just
  14654. before terminating themselves, when you know they could have processed
  14655. what they were doing, give the memory back, and then try to continue.
  14656. JDNowland.
  14657. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  14658.  
  14659. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35LE0934 Date: 05/17/90
  14660. From: JIM NICKEL                                            Time: 10:15 am
  14661.   To: ALL                                                   (Read 73 times)
  14662. Subj: PRINTER TESTING IN TURBO C
  14663.  
  14664. Is there a way in TC to determine if a printer is connected and/or on-line
  14665. before data is sent to it?  I have a program that does not behave nicely
  14666. if I try to send something to a non-existant printer.
  14667. Jim
  14668. ---------------
  14669.  
  14670. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35LQ2070 Date: 05/17/90
  14671. From: JOHN ABATTE                                           Time: 09:34 pm
  14672.   To: ALL                                                   (Read 71 times)
  14673. Subj: TC++
  14674.  
  14675. Howdy all,
  14676.  
  14677.     Heard about the TC++ announcement last PM here on the BBS. Anyone
  14678. have any more detailed info regarding the release? When's it due, what
  14679. it is, upgrade co$t, bennies, etc, etc.
  14680.  
  14681.     Sorry folks, but the rumor-mongers have had me chomping at the bit
  14682. for the past couple'a months. Now that Borland's blown the cover on it
  14683. (presumably via Compuserve, among others), I suddenly feel the need for
  14684. more "substantial" rumors.
  14685.  
  14686. Thanx...John.
  14687. ---------------
  14688. Following thread
  14689.  
  14690. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35LR0699 Date: 05/17/90
  14691. From: ROBERT BALSOVER                                       Time: 10:11 pm
  14692.   To: JOHN ABATTE (Rcvd)                                    (Read 71 times)
  14693. Subj: R: TC++
  14694.  
  14695. John,
  14696. I uploaded the press release Borland posted in their CIS forem, you'll
  14697. find it the MS-DOS collection here.
  14698. Bob
  14699. ---------------
  14700. ** Current thread: TC++
  14701.  
  14702. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35MN2696 Date: 05/18/90
  14703. From: JOHN ABATTE                                           Time: 07:44 pm
  14704.   To: ROBERT BALSOVER (Rcvd)                                (Read 70 times)
  14705. Subj: R: TC++
  14706.  
  14707. Thanks a bunch! I found the TC++ message last night before I logged off.
  14708.  
  14709. The whole Pro package sounds pretty good so I went ahead and ordered it
  14710. today. Should have it in a couple'a two or four weeks. Looking forward to
  14711. learning C++, and I,ve been tempted to get the Zortech package, but when I
  14712. first heard the rumors about TC++ many, many months ago I decided to wait.
  14713.  
  14714. Thanks again for the help, and the release note. I appreciate it.
  14715.  
  14716. Ciao, John.
  14717. ---------------
  14718. ** Current thread: TC++
  14719.  
  14720. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3A5P2105 Date: 06/05/90
  14721. From: JOSEPH KARAS                                          Time: 08:35 pm
  14722.   To: ALL                                                   (Read 77 times)
  14723. Subj: TC++
  14724.  
  14725. TC++ PRO arrived today, looks like its going to be a busy summer.  From
  14726. the brief time I've used it (3+hours) its pretty Impressive.
  14727. There is a learning curve because of all the new features and getting
  14728. use to a rodent.  It has compiled all the stuff I threw at it so far.
  14729. Back to fun time.
  14730. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  14731.  
  14732. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35NQ1876 Date: 05/19/90
  14733. From: GREGORY WILSON                                        Time: 09:31 pm
  14734.   To: ALL                                                   (Read 69 times)
  14735. Subj: CXL LIBS
  14736.  
  14737. Has anyone heard from Mike Smedley (author of CXL 'C' libs)? It has been
  14738. almost 4 weeks since I mailed my registration and have not received
  14739. anything. I logged on his BBS and left msg after msg pleading for at least
  14740. some type of acknowledgement and got nothing. Has he dropped off the
  14741. earth? Should I cancel my check? Can I still get the CXL stuff?
  14742. Someone reassure me!
  14743. Thanks
  14744. Gregory Wilson
  14745. (GREG WILSON on Mike's BBS)
  14746. ---------------
  14747. Following thread
  14748.  
  14749. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35PR0311 Date: 05/20/90
  14750. From: GLEN THOMPSON                                         Time: 10:05 pm
  14751.   To: GREGORY WILSON (Rcvd)                                 (Read 75 times)
  14752. Subj: R: CXL LIBS
  14753.  
  14754. Greg,
  14755.  
  14756. From what I heard, Mike recently changed jobs which has left him almost no
  14757. free time.  In addition, the service he was using to copy diskettes really
  14758. fouled things up so nothing got sent out like it was supposed to.
  14759.  
  14760. Mike probably should have paid a little more attention to the BBS but
  14761. that's one of the problems in dealing with a one man operation.  Given the
  14762. features vs. price of CXL, it's a bargin.  This recent problem is the
  14763. first I've seen in dealing with CXL and the BBS in over a year.
  14764.  
  14765. glen
  14766. ---------------
  14767. ** Current thread: CXL LIBS
  14768.  
  14769. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35QC2587 Date: 05/21/90
  14770. From: GREGORY WILSON                                        Time: 08:43 am
  14771.   To: GLEN THOMPSON (Rcvd)                                  (Read 72 times)
  14772. Subj: R: CXL LIBS
  14773.  
  14774. Well, I guess I will just keep waiting. For the price CXL cannot
  14775. be beat. I have looked into the WindowBoss libs but they do not
  14776. have the 'remapped' direct screen writes that will work in
  14777. Desqview. They only suggest going to BIOS video which is too
  14778. slow. Anyway, I appreciate the information. If you hear anything
  14779. else, don't forget me.
  14780. Thanks again!
  14781. Gregory Wilson
  14782.  
  14783. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  14784.  
  14785. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35P22832 Date: 05/20/90
  14786. From: DAVE KARR                                             Time: 02:47 am
  14787.   To: ALL                                                   (Read 69 times)
  14788. Subj: GET A JOB!
  14789.  
  14790.  
  14791.                            Wanted:  Software Engineer
  14792.  
  14793.         We are currently looking for an individual interested in working
  14794.         on new product designs in the medical field.  If you have experi-
  14795.         ence in real time programming in assembly and 'C' and/or PLM with
  14796.         the INTEL 51, and 196 family of uP then I'd like to talk to you.
  14797.  
  14798.         You would be responsible for the entire product software system
  14799.         structure, development, and testing.  The need is immediate with
  14800.         three projects underway, four to six over the next two to three
  14801.         years, and current product maintainence.  This is a full time
  14802.         salaried position with benefits.
  14803.  
  14804.         Interested?.... Serious?.... Talk to me!....
  14805.  
  14806.         Leave a Private Message here.
  14807.  
  14808.         Or Call 781-5650 Weekdays 8AM to 6PM
  14809.  
  14810.  
  14811.                                     Dave Karr
  14812.  
  14813.  
  14814. ---------------
  14815.  
  14816. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35PJ2285 Date: 05/20/90
  14817. From: RICHARD WAMSER                                        Time: 03:38 pm
  14818.   To: ALL                                                   (Read 71 times)
  14819. Subj: INTERRUPTS
  14820.  
  14821. I would appreciate any information on how to Program the Second Interrupt
  14822. controller on a AT Class Computer to Enable the Hardware Interrupts. I
  14823. have sent out values to Port A1 which I thought controlled the enabling
  14824. and disabling of the Hardware Interrupts but no matter what I sent out I
  14825. could not Enable Hardware Interrupts IRQ0 or IRQ11 all I managed to do was
  14826. hang up the machine so that nothing worked ( had to cycle the power switch
  14827. ) so if any one has any ideas on how to enable the Hardware Interrupts
  14828. please give me your ideas or thoughts
  14829. Richard
  14830. ---------------
  14831. Following thread
  14832.  
  14833. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35PK3021 Date: 05/20/90
  14834. From: JEFF NOWLAND                                          Time: 04:50 pm
  14835.   To: RICHARD WAMSER (Rcvd)                                 (Read 74 times)
  14836. Subj: R: INTERRUPTS
  14837.  
  14838. Rich,
  14839. I don't do a lot with IRQs but I do know the following:
  14840. 1. The second controller is at I/O ports A0 and A1 and the eoi(20h) that
  14841. you need to send to signal end of interrupt goes to port A0. 2) the
  14842. controller is cascaded through the first controller, so any handler that
  14843. is responsible for sending and eoi to the 2nd controller may also be
  14844. responsible for sending an eoi to the first controller.  3) the
  14845. controller enables are bit mapped for which IRQs they will let through, so
  14846. you need to make sure that you aren't activating one IRQ and
  14847. simultaneously deactivating another.(I have some code from a while back
  14848. that I used to do these things, I'll try to find it and upload, probably
  14849. late this week or next weekend.
  14850. JDNowland.
  14851. ---------------
  14852. ** Current thread: INTERRUPTS
  14853.  
  14854. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35PP1992 Date: 05/20/90
  14855. From: RICHARD WAMSER                                        Time: 08:33 pm
  14856.   To: JEFF NOWLAND (Rcvd)                                   (Read 75 times)
  14857. Subj: R: INTERRUPTS
  14858.  
  14859. JEFF;
  14860. Thanks for the reply.  The basics of what you said I got from a book that
  14861. I bought "THE XT-AT HANDBOOK" put out by ANNABOOKS it  is a very good book
  14862. on the basics of the XT-AT and gave some of the same basic information
  14863. that you did, but it didn't give me any detailed info on how to implament
  14864. and the specifics of what is needed to use a Hardware Interrupt.  I wish I
  14865. could find a book that told me in very simple terms how to do some of
  14866. these things. Iam looking forward to hearing from you again hopelly you
  14867. might have some more information and or some Code on how to use a Hardware
  14868. Interrupt Thanks again for sharing some of your knowledge and time with me
  14869. Rich
  14870. ---------------
  14871. ** Current thread: INTERRUPTS
  14872.  
  14873. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35QP0173 Date: 05/21/90
  14874. From: THIERRY GIRON                                         Time: 08:02 pm
  14875.   To: RICHARD WAMSER (Rcvd)                                 (Read 74 times)
  14876. Subj: R: INTERRUPTS
  14877.  
  14878. Richard;
  14879. The Book I mostly use when it comes to hardware interrupt is called
  14880. SYSTEM BIOS for IBM PC/XT/AT computers and compatible
  14881. This book was published by Phoenix itself and is very accurate on what
  14882. the interrupts do and also provides a lot of specification on the chips
  14883. used in a PC. Unfortunately, it does not give enough examples.
  14884. Thierry.
  14885. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  14886.  
  14887. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35PK1509 Date: 05/20/90
  14888. From: WALTER STHOKAL                                        Time: 04:25 pm
  14889.   To: ALL                                                   (Read 71 times)
  14890. Subj: QC AND MOUSE
  14891.  
  14892.      While using QC with the /h switch on an EGA monitor, the mouse works
  14893. quite nicely as expected.  However, if the screen is toggled to output by
  14894. F4,
  14895. running the program, or by compiling, the mouse pointer only appears in
  14896. the
  14897. top 2/3 of the screen.  Mouse select buttons are active in the lower part
  14898. of
  14899. the screen but it is somewhat inconvenient to be required to guess at the
  14900. location of the selection.  Has anyone else experienced this?
  14901. Equipment list:
  14902. 286 clone 1.2meq RAM
  14903. Logitec C7 mouse in comm1
  14904. ATI-2400etc in comm3
  14905. Boca EGA card driving a NEC 3D
  14906. --Thanks in advance,
  14907.            Wally
  14908.  
  14909.  
  14910. ---------------
  14911.  
  14912. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35QL0108 Date: 05/21/90
  14913. From: DALE KLIPSTEIN                                        Time: 05:01 pm
  14914.   To: ALL                                                   (Read 71 times)
  14915. Subj: WANTED BBS WITH C SRC
  14916.  
  14917. I'm looking for a BBS that will run on a IBM XT or higher that includes
  14918. the source code, preferably in Turbo C.
  14919.  
  14920. Does anyone know of any?  I can't seem to find one on Exec-PC.
  14921.  
  14922. P.S. I'd rather not reinvent the wheel if I don't have to.
  14923.  
  14924. Dale
  14925. ---------------
  14926.  
  14927. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35QP0513 Date: 05/21/90
  14928. From: THIERRY GIRON                                         Time: 08:08 pm
  14929.   To: ALL                                                   (Read 73 times)
  14930. Subj: WINDOW 386
  14931.  
  14932. Hello there,
  14933. I am finishing the development of an operating system compatible with
  14934. MS-DOS 3.3 and to some extent 4.1. Right now, I can run most of
  14935. applications including WINDOWS 286 and GEM programs like VENTURA. However,
  14936. I still have a problem running WINDOWS 386. It seems that it hooks itself
  14937. in a very strange way inside the MS-DOS kernel at some adress with a fix
  14938. offset from the adress of the LIST of LIST of DOS.
  14939. Is there any body out there that knows what trick WINDOWS 386 is using !?
  14940. I cannot reaaly see myslf dissassembling WINDOWS to find out what goes
  14941. wrong. If you have any suggestions, I would appreciate to learn from you.
  14942. Thierry.
  14943. ---------------
  14944.  
  14945. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35RL1768 Date: 05/22/90
  14946. From: SCOTT CHAMBERLAIN                                     Time: 05:29 pm
  14947.   To: ALL                                                   (Read 85 times)
  14948. Subj: FPRINTF PROBLEM IN TC2.0
  14949.  
  14950. HELP!
  14951.  
  14952. I am writing this as I lose whatever small amount of hair I have!  I am
  14953. writing a program that prints out some doubles, i.e.:
  14954.  
  14955. double v[5];
  14956.  
  14957.  
  14958. for ( i = 0; i < 5; i++ ) {
  14959.     fprintf( stdprn, "%8.2f\n", v[i] );
  14960. }
  14961.  
  14962. and when I run it, some of the "%8.2f"'s work and some of them don't!
  14963. When I look at the value of the array variable, it is a correct, double
  14964. value, yet when I print it I get something like
  14965. "7.88040123927889584<bunch of zeroes>e+115" for the double value that
  14966. should print "1494.00".  Yet, if I sum that value into another double
  14967. array and then print it, I get the right representation!
  14968.  
  14969. I am using TC2.0, TD1.0, with all the current patches that I downloaded
  14970. from CIS (dated April 17, 1990).
  14971.  
  14972. What is going on?  Am I going nuts?
  14973.  
  14974. Perplexedly,
  14975.    Scott
  14976. ---------------
  14977. Following thread
  14978.  
  14979. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35RL2481 Date: 05/22/90
  14980. From: GRANT ELLSWORTH (Leader)                              Time: 05:41 pm
  14981.   To: SCOTT CHAMBERLAIN (Rcvd)                              (Read 89 times)
  14982. Subj: R: FPRINTF PROBLEM IN TC2.0
  14983.  
  14984. Scott ,, That's one of the flakiest errors I've seen reported for TC.
  14985. It seems to me like the parameter being passed to fprintf() is not being
  14986. passed consistently (by structure of the argument list).  I suggest you
  14987. try the following:
  14988.  
  14989.    fprintf(stdprn, "%8.2f\n", (double)v[i]);
  14990.  
  14991. The explicit typecasting may obviate whatever insufficiency TC's parameter
  14992. list construction is coming up with.  We'd have to look carefully at the
  14993. genned code to see what the misfire really was.  I've always been a little
  14994. gunshy of letting the compiler's handling of variable length argument
  14995. lists with the several parameters having mixed and implied types take con-
  14996. trol.  Grant
  14997. ---------------
  14998. ** Current thread: FPRINTF PROBLEM IN TC2.0
  14999.  
  15000. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35SD1235 Date: 05/23/90
  15001. From: SCOTT CHAMBERLAIN                                     Time: 09:20 am
  15002.   To: GRANT ELLSWORTH (Rcvd)                                (Read 84 times)
  15003. Subj: R: FPRINTF PROBLEM IN TC2.0
  15004.  
  15005. Thanks for the lead, I will follow it up today.  I should have thought to
  15006. try the explicit cast.
  15007.  
  15008. If I can't get it to work this morning, then I guess I will have to open
  15009. the "dreaded CPU window" on my copy of TD and look at what is really
  15010. happening.  I am beginning to concur with your feeling re: variable length
  15011. argument lists & type mixing.
  15012.  
  15013. I will let you know what happened, either way.
  15014.  
  15015. Later,
  15016.    Scott
  15017. ---------------
  15018. ** Current thread: FPRINTF PROBLEM IN TC2.0
  15019.  
  15020. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35SL1807 Date: 05/23/90
  15021. From: GRANT ELLSWORTH (Leader)                              Time: 05:30 pm
  15022.   To: SCOTT CHAMBERLAIN (Rcvd)                              (Read 78 times)
  15023. Subj: R: FPRINTF PROBLEM IN TC2.0
  15024.  
  15025. Dread not the CPU Window ... it is sometimes the most informative one
  15026. you'll have.  Well, I'm looking forward to your final assessment of your
  15027. strange problem.  Grant
  15028. ---------------
  15029. ** Current thread: FPRINTF PROBLEM IN TC2.0
  15030.  
  15031. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35U50262 Date: 05/25/90
  15032. From: GUY SIMMONS                                           Time: 05:04 am
  15033.   To: SCOTT CHAMBERLAIN (Rcvd)                              (Read 77 times)
  15034. Subj: R: FPRINTF PROBLEM IN TC2.0
  15035.  
  15036. Hi Scott -
  15037.      Sorry to ask such a silly question, but are you by any chance walking
  15038. off the end of your array? I could not reproduce the problem with:
  15039.      double v[5];
  15040.      for (i = 0; i < 5; i++)
  15041. but I got the same type of error with
  15042.      double v[5];
  15043.      for (i = 0; i <= 5; i++)
  15044. I hope this helps.
  15045. Guy
  15046. ---------------
  15047. ** Current thread: FPRINTF PROBLEM IN TC2.0
  15048.  
  15049. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35YC2545 Date: 05/29/90
  15050. From: SCOTT CHAMBERLAIN                                     Time: 08:42 am
  15051.   To: GRANT ELLSWORTH (Rcvd)                                (Read 72 times)
  15052. Subj: R: FPRINTF PROBLEM IN TC2.0
  15053.  
  15054. I currently don't have the total scoop yet, but when I use a format string
  15055. that does not include the vertical bar ('|') it works.  I got the program
  15056. to work by separating all my fprintf calls to one value at a time, and
  15057. then it worked.
  15058.  
  15059. If I get a chance this week I will try to trace through the library and
  15060. find out why it didn't like what it was seeing for some reason.  I just
  15061. tend to get a little steamed when you have to work around something that
  15062. should work.
  15063.  
  15064. Later,
  15065.    Scott
  15066. ---------------
  15067. ** Current thread: FPRINTF PROBLEM IN TC2.0
  15068.  
  15069. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35YC3539 Date: 05/29/90
  15070. From: SCOTT CHAMBERLAIN                                     Time: 08:59 am
  15071.   To: GUY SIMMONS (Rcvd)                                    (Read 74 times)
  15072. Subj: R: FPRINTF PROBLEM IN TC2.0
  15073.  
  15074. Thanks for the lead, but I doublechecked that before I called.  I finally
  15075. got the program to run by using individual calls to fprintf without any
  15076. other literals in the format string, i.e.
  15077.  
  15078.      fprintf(stdprn,"%8.2f |",v[i]);     --won't work
  15079.  
  15080.      fprintf(stdprn,"%8.2f ",v[i]);      --will work
  15081.      fprintf(stdprn,"|");
  15082.  
  15083. As I said to Grant in a prior reply, I will use TD and the CPU Window to
  15084. trace through the library and find out why the baby (TC) insists on
  15085. spitting up on perfectly good syntax.
  15086.  
  15087. Later,
  15088.    Scott
  15089. ---------------
  15090. ** Current thread: FPRINTF PROBLEM IN TC2.0
  15091.  
  15092. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35YP1390 Date: 05/29/90
  15093. From: GRANT ELLSWORTH (Leader)                              Time: 08:23 pm
  15094.   To: SCOTT CHAMBERLAIN (Rcvd)                              (Read 71 times)
  15095. Subj: R: FPRINTF PROBLEM IN TC2.0
  15096.  
  15097. Scott, In the form that does NOT work, examine closely the parameter list
  15098. construction code for "anomalies".  Also, I wonder if the vertical bar
  15099. has meaning to TC's format processor --- ergo, revisit the docs to see if
  15100. that is one of those special characters which must be coded with a prec-
  15101. eding back-slash.  btw, I'm going to construct a simple minded example to
  15102. replicate the problem out of context.  Let us know what you come up with.
  15103. ... Grant
  15104. ---------------
  15105. ** Current thread: FPRINTF PROBLEM IN TC2.0
  15106.  
  15107. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35YP1652 Date: 05/29/90
  15108. From: GRANT ELLSWORTH (Leader)                              Time: 08:27 pm
  15109.   To: SCOTT CHAMBERLAIN (Rcvd)                              (Read 71 times)
  15110. Subj: R: FPRINTF PROBLEM IN TC2.0
  15111.  
  15112. Scott, btw, you left out the "|" your original problem statement.  And
  15113. some of us went on a snipe hunt.  I think we all have to be real careful
  15114. when we are brining a problem to the floor ... and be sure that we have
  15115. included all the relevant elements.  Grant
  15116. ---------------
  15117. ** Current thread: FPRINTF PROBLEM IN TC2.0
  15118.  
  15119. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35ZC2321 Date: 05/30/90
  15120. From: SCOTT CHAMBERLAIN                                     Time: 08:38 am
  15121.   To: GRANT ELLSWORTH (Rcvd)                                (Read 71 times)
  15122. Subj: R: FPRINTF PROBLEM IN TC2.0
  15123.  
  15124. First of all, mea culpa on leaving out the bar.  I have looked through the
  15125. documentation and through the Waite Group's Turbo C Bible, and neither
  15126. call out the bar as something that needs an escape sequence.  In fact, as
  15127. a quick peruse of the Waite Group book shows that the character
  15128. classification macros classify the verical bar, hex 0x7C, as a punctuation
  15129. character, not a control character that needs an escape sequence.
  15130.  
  15131. I guess that I assumed a punctuation character wouldn't affect the format
  15132. string as long as it wasn't a special one (i.e. a \ or a % that are
  15133. formally defined as special sequence start characters in the format
  15134. string).  The other assumption was that it had to be something obscure or
  15135. that there would be at least some mention of it in the bug reports or
  15136. patches that are available here.
  15137.  
  15138. To take the discussion even further, there were other problems that
  15139. occurred at different parts of my investigation here.  At one time I had a
  15140. fprintf call that went like...
  15141.  
  15142. fprintf(stdprn,"%18s %40s %5.5d %5.5d %8.2f |",st1,st2,int1,int2,fl);
  15143.  
  15144. with correct, non-zero values in the ints and the float.  When I looked at
  15145. the output, the first int would print correctly, the second always as
  15146. zero, and the float as a exponential number out in the stratosphere some
  15147. place.  Note that the bar is at the end of the format string, after the
  15148. float, and would always print correctly (was never dropped out).  The only
  15149. way I got it to work at the end was to call each numeric print as a
  15150. separate fprintf call, and without the "punctuation" that I wanted.
  15151.  
  15152. Later,
  15153.    Scott
  15154. ---------------
  15155. ** Current thread: FPRINTF PROBLEM IN TC2.0
  15156.  
  15157. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35ZP1826 Date: 05/30/90
  15158. From: GRANT ELLSWORTH (Leader)                              Time: 08:30 pm
  15159.   To: SCOTT CHAMBERLAIN (Rcvd)                              (Read 72 times)
  15160. Subj: R: FPRINTF PROBLEM IN TC2.0
  15161.  
  15162. Scott, The behavior you describe has happened to me when I've got some
  15163. piece of wild code clobbering the stack before I issued the output state=
  15164. ment (fprintf,,, printf, or whatever).  I made a small sample program with
  15165. your sample fprintf() and an accompanying printf() along with an array
  15166. of double values - set and printed in separate loops.  I tried ALL memory
  15167. models except tiny and huge, the array declared global and local ... in
  15168. all cases everything worked as expected.  So I suspect that you have some
  15169. operation somewhere that is walking all over your variables, or what you
  15170. THINK you have in your fprintf() routine and what you actually have is
  15171. not the same.  That is, you are probably looking at an insect of your own
  15172. device.  Grant
  15173. ---------------
  15174. ** Current thread: FPRINTF PROBLEM IN TC2.0
  15175.  
  15176. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35^C2424 Date: 05/31/90
  15177. From: SCOTT CHAMBERLAIN                                     Time: 08:40 am
  15178.   To: GRANT ELLSWORTH (Rcvd)                                (Read 72 times)
  15179. Subj: R: FPRINTF PROBLEM IN TC2.0
  15180.  
  15181. I understand your position, but I don't think there is anything I am doing
  15182. that would change the fprintf call - if I was messing up the stack, it
  15183. wouldn't matter that I broke the calls up or did it in one call.  When I
  15184. used the variable inspection window after breaking on the line with the
  15185. fprintf call (and nothing else on that line) the variables had actual
  15186. values -- as also verified that running totals were being computed
  15187. correctly, and when the only change I made in the code was going from:
  15188.  
  15189. fprintf(stdprn,"%18s %40s %5.5d %5.5d %8.2f |",s1,s2,i1,i2,d1);
  15190.  
  15191. to
  15192.  
  15193. fprintf(stdprn,"%18s ",s1);
  15194. fprintf(stdprn,"%40s ",s2);
  15195. fprintf(stdprn,"%5.5d ",i1);
  15196. fprintf(stdprn,"%5.5d ",i2);
  15197. fprintf(stdprn,"%8.2f ",d1);
  15198. fprintf(stdprn,"|");
  15199.  
  15200. Now, I admit that I didn't cut the above samples directly out of the code
  15201. file, but they are "reasonable facimiles" of the real thing.  And, that is
  15202. the ONLY thing I changed between the erroneous and correctly running
  15203. versions.
  15204.  
  15205. Not only that, if I had something trashing the stack, the program would be
  15206. crashing a lot harder that just print anomalies, as that is where all the
  15207. function return addresses are stored, right?  Why would something only
  15208. trash variables on the stack and not return addresses?
  15209.  
  15210. I would also say you were right if I were calling one of my functions
  15211. within the fprintf statement to return a value to be printed, rather than
  15212. computing all the numbers and then printing out the variables without
  15213. having to figure out anything more than, say, a pointer reference for an
  15214. array variable.
  15215.  
  15216. Also, I may be guilty of obscuring the problem by including the array in
  15217. the question.  A code stub of:
  15218.  
  15219.      q = wq[i];
  15220.      v = wv[i];
  15221.      fprintf(stdprn,"%4d %8.2f |",q,v);
  15222.  
  15223. worked just as bad as:
  15224.  
  15225.      fprintf(stdprn,"%4d %8.2f |",wq[i],wv[i]);
  15226.  
  15227. and the only thing that worked was to use three fprintf calls, one for the
  15228. int, one for the double, and one for the literal "|".
  15229.  
  15230. By the way, the program is producing valid output now that I went through
  15231. and applied the "workaround" cited in the sentence above (breaking up the
  15232. fprintf calls).
  15233.  
  15234. Later,
  15235.    Scott
  15236.  
  15237. P.S. If you want to see the program, or an .EXE with debugging information
  15238. along with test data files, let me know and I will upload it for your
  15239. perusal.
  15240.  
  15241. SRC
  15242. ---------------
  15243. ** Current thread: FPRINTF PROBLEM IN TC2.0
  15244.  
  15245. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35^P1367 Date: 05/31/90
  15246. From: GRANT ELLSWORTH (Leader)                              Time: 08:22 pm
  15247.   To: SCOTT CHAMBERLAIN (Rcvd)                              (Read 72 times)
  15248. Subj: R: FPRINTF PROBLEM IN TC2.0
  15249.  
  15250. Scott, DO upload and leave msg ... both source and debugaable .exe would
  15251. be appreciated.  I think I'll be able to isolate probable cause.  Be sure
  15252. to include memory model info and other config.tc info (or ship the
  15253. tcconfig.tc you are using).  There is one awful glitch in what I can do,
  15254. I can't print to stdprn.  So try your program writing to a standard stream
  15255. file and see if you are getting the same befoulement 1st.  Then ship the
  15256. stuff and I'll see what I can do.  good luck,  Grant
  15257. ---------------
  15258. ** Current thread: FPRINTF PROBLEM IN TC2.0
  15259.  
  15260. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3A1E2324 Date: 06/01/90
  15261. From: SCOTT CHAMBERLAIN                                     Time: 10:38 am
  15262.   To: GRANT ELLSWORTH (Rcvd)                                (Read 84 times)
  15263. Subj: R: FPRINTF PROBLEM IN TC2.0
  15264.  
  15265. Ok, I will try a version that uses another file rather than the standard
  15266. printer handle.
  15267.  
  15268. Also, I thought I saw a LPT: redirection utility somewhere in Bob's
  15269. collection -- about three years ago I was fighting with a printer
  15270. manufacturer about what a printer was doing with a data stream, and I
  15271. finally proved to him that the printer specs were wrong and my program
  15272. right by capturing the print stream to disk.  If I can dig it up I will
  15273. point you to it.
  15274.  
  15275. Later,
  15276.    Scott
  15277. ---------------
  15278. ** Current thread: FPRINTF PROBLEM IN TC2.0
  15279.  
  15280. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3A211461 Date: 06/02/90
  15281. From: GRANT ELLSWORTH (Leader)                              Time: 12:24 am
  15282.   To: SCOTT CHAMBERLAIN (Rcvd)                              (Read 81 times)
  15283. Subj: R: FPRINTF PROBLEM IN TC2.0
  15284.  
  15285. Scott, I tried the following skeleton program in ALL memory models.  It
  15286. worked in all cases.  Try compiling this with your compiler.  If it works,
  15287. then I would conclude that you have something somewhere walking on some-
  15288. thing the TC fprintf() support routines need or use when handling multi-
  15289. ple operand fprintf() argument lists - or that the argument list on the
  15290. stack is NOT what the fprintf() function is expecting in the multi-oper-
  15291. and case.
  15292.  
  15293. Note: if you are using the standalone debugger, then look at the stack
  15294. contents.  Use the ptrs on the stack to view the actual data in the DUMP
  15295. part of the cpu window to see if you are looking at what you expect at
  15296. those seg:ofs locations.
  15297.  
  15298. I should note that the type of error you report HAS happened to me with
  15299. similar manifestations when I have inadvertantly linked a chunk compiled
  15300. with one memory model with libs for another --- e.g. compiled module with
  15301. small model and linked using compact model. The TC IDE is vulnerable to
  15302. this kind of stumble since you can change the memory model in the OPTIONS
  15303. menu and have an unchanged source/object lying around.  Hence when you
  15304. "MAKE" the .EXE, the IDE assumes all is ok for relink without recompile.
  15305.  
  15306. The more common manifestation, however, is a lockup requiring "big red"
  15307. to get control back.
  15308.  
  15309. #include <stdio.h>
  15310.  
  15311. void main(void)
  15312. {
  15313.     int i;
  15314.     double v[5];
  15315.     char s1[19] = "{char string - 18}";
  15316.     char s2[41] = "{char string of 40 min ...(RJUST)...}";
  15317.     int i1 = 5;
  15318.     int i2 = 23;
  15319.     double d1 = 1234.56;
  15320.     FILE * fpx;
  15321.  
  15322.     for (i = 0; i < 5; i ++) {
  15323.         v[i] = ((double) i * 1000) + ((double) i * .05);
  15324.         }
  15325.     fpx = fopen("fpx.tst", "w+");
  15326.     for (i = 0; i < 5; i ++) {
  15327.         fprintf(fpx, "%4d, %8.2f |", i, v[i]);
  15328.         printf("%4d %8.2f |", i, v[i]);
  15329.         }
  15330.     fprintf(fpx,"\n");
  15331.     printf("\n");
  15332.     fprintf(fpx,"%18s %40s %5.5d %5.5d %8.2f |",s1,s2,i1,i2,d1);
  15333.     printf("%18s %40s %5.5d %5.5d %8.2f |",s1,s2,i1,i2,d1);
  15334.     fclose(fpx);
  15335. }
  15336.  
  15337. BTW, you can still upload your code and .exe for examination if you like.
  15338.  
  15339. Grant
  15340. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  15341.  
  15342. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35TC3374 Date: 05/24/90
  15343. From: DON BOWEN                                             Time: 08:56 am
  15344.   To: ALL                                                   (Read 76 times)
  15345. Subj: ASSEMBLY BOOKS
  15346.  
  15347. I know that this is a C forum, but I am hoping this is also where all the
  15348. assembly language "gurus" hang out.  I am looking for the best assembly
  15349. language book I can find.  I have a couple and have seen others, but still
  15350. don't have what I want.  I want something to show me why I should use an
  15351. XOR AX,AX instead of SUB AX,AX to zero a register (or why not).  I want to
  15352. learn all the quick and dirty tricks (or at least quite a few!).  Peter
  15353. Norton's book and Que's Assembly Language book are very poor in my
  15354. opinion.  They are also more for beginners.  Can anyone help me?
  15355.  
  15356. One C question that I do have is how does a program like Dbase handle
  15357. temporary variables?  How does it deal with temporary results in stmts
  15358. like:  STRING = LTRIM(TRIM(STR(VAL(NUMBER),)))?
  15359.  
  15360. Thanks.
  15361.  
  15362. Don
  15363. ---------------
  15364. Following thread
  15365.  
  15366. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35TP1808 Date: 05/24/90
  15367. From: GRANT ELLSWORTH (Leader)                              Time: 08:30 pm
  15368.   To: DON BOWEN (Rcvd)                                      (Read 77 times)
  15369. Subj: R: ASSEMBLY BOOKS
  15370.  
  15371. Don, ...\
  15372.  
  15373. re: Assembly Language for 80x86 processors ...
  15374.  
  15375. ALL the books on 80x86 ASM which I've seen are no better than the one's
  15376. you mentioned.  The book I found most useful was: Assembly Language Pro-
  15377. gramming for the IBM Personal Computers, by David J. Bradley, published by
  15378. Prentice Hall - my edition was printed in 1984
  15379.  
  15380. This particular edition was on the 8086/8088 only.  The book predates the
  15381. widespread use or introduction of the 80286 and 80386.  Well, when I
  15382. taught myself ASM, the 8088/8086 was all there was..  Today, the book is
  15383. definitely dated, but it did have good examples from which one could
  15384. develop more sophisticated constructs.
  15385.  
  15386. To really get the handle on any machine's native assembler/instruction set
  15387. just requires lots of patience, time, and discipline.  I have yet to see
  15388. ANY book on ANY assembly language which effectively addresses advanced
  15389. techiques, constructs, etc..
  15390.  
  15391. Maybe somebody should write one and make some $$$ off of it. ...
  15392.  
  15393. re: DBASE and temporary variables ...
  15394.  
  15395. I'm pretty sure that dbase allocates a fair amount of storage space for
  15396. the temporary variables in the expression you listed.  One of the releases
  15397. of dbase I've seen showed the amount of temporary storage which was
  15398. available in the DISPLAY MEMORY (? - not 100% sure) command.
  15399.  
  15400. Grant
  15401. ---------------
  15402. ** Current thread: ASSEMBLY BOOKS
  15403.  
  15404. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35UC1252 Date: 05/25/90
  15405. From: STEVEN KEY                                            Time: 08:20 am
  15406.   To: DON BOWEN (Rcvd)                                      (Read 76 times)
  15407. Subj: R: ASSEMBLY BOOKS
  15408.  
  15409. Don,
  15410.  
  15411. After reading this message, I think I can say that Michael Abrash's book
  15412. "Zen of Assembly Language" is what you're looking for.  Vol 1 is out, with
  15413. Vol 2 to be published later this year.  Vol 1 is entirely devoted to just
  15414. the kind of questions as whether SUB AX,AX is better than XOR AX,AX.  Vol
  15415. 2 will be concerned with questions at a higher level.  Abrash has written
  15416. a column in Programmers Journal for a number of years.
  15417.  
  15418. Steven
  15419. ---------------
  15420. ** Current thread: ASSEMBLY BOOKS
  15421.  
  15422. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35UI1135 Date: 05/25/90
  15423. From: DON BOWEN                                             Time: 02:18 pm
  15424.   To: GRANT ELLSWORTH (Rcvd)                                (Read 73 times)
  15425. Subj: R: ASSEMBLY BOOKS
  15426.  
  15427. Grant, funny you should mention the Bradley book.  I cut my teeth on that
  15428. book and have been looking for it ever since.  It was very basic, but
  15429. blows away Norton's book (he doesn't even cover the entire command set!).
  15430. I was talking to Eric Issacson, author of ZIPKEY, about writing a book on
  15431. assembly.  He is also the author of A86 and D86, so he knows a little bit
  15432. about assembly!  He said he has thought many times of doing that, but
  15433. other things are higher on his priority list.  I have yet to see a basic
  15434. assembly book tell you that the DI register is related CLOSELY to the ES
  15435. segment register!  When you are starting out that can be confusing.  I am
  15436. far (I think!) from a beginner and yet still have a long way to go.  I
  15437. still believe that a program should be written as tight as possible.  I am
  15438. not impressed that we have developed ways to write programs that can be
  15439. larger than 640K!  Today's programmers are not poorer programmers, just
  15440. lazier (ok, this is just an opinion).  Thank you for your response and if
  15441. you know where I can get that book please let me know.  Don.
  15442. ---------------
  15443. ** Current thread: ASSEMBLY BOOKS
  15444.  
  15445. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35UP0858 Date: 05/25/90
  15446. From: GRANT ELLSWORTH (Leader)                              Time: 08:14 pm
  15447.   To: DON BOWEN (Rcvd)                                      (Read 74 times)
  15448. Subj: R: ASSEMBLY BOOKS
  15449.  
  15450. Don, Maybe the Bradley book is still in print.  If so, you might be able
  15451. to order thru either a tech bookstore near a University or B. Dalton,
  15452. Booksellers.  Seems to me that I did see a book on IBM PC  ASM which
  15453. looked like an "update" to the original Bradley book at a local tech book
  15454. store.  Anyway, the booksellers should have the current edition of "BOOKS
  15455. IN PRINT" and you should be able to find out availability of the original
  15456. or an update to the Bradley book.
  15457.  
  15458. Re: "Today's programmers " ... I don't agree.  They are not  lazier.  They
  15459. just seem to have a narrower focus than desirable.  When I entered this
  15460. "arcane" line of "misadventure", you were expected to learn the essentials
  15461. of the machine's instruction set and architecture before you went on to
  15462. more "sophisticated" languages (like C***L).  Nowadays, seems like the MIS
  15463. and CSC programs  are turning out folks who are totally ignorant of
  15464. machine language and architecture.   Grant
  15465. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  15466.  
  15467. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35XK2460 Date: 05/28/90
  15468. From: DEAN EGGERT                                           Time: 04:41 pm
  15469.   To: ALL                                                   (Read 70 times)
  15470. Subj: MULTITASKING IN C
  15471.  
  15472. Anybody out there using Ctask? I would be interested in talking about
  15473. Ctask.
  15474. ---------------
  15475.  
  15476. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 35ZN1836 Date: 05/30/90
  15477. From: THOMAS ZERUCHA                                        Time: 07:30 pm
  15478.   To: ALL                                                   (Read 69 times)
  15479. Subj: MIX POWER C 2.0
  15480.  
  15481. The upgrade is available now.  I haven't recieved mine yet, but it is able
  15482. to do small and large models (maybe more).
  15483. ---------------
  15484.  
  15485. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3A1D0730 Date: 06/01/90
  15486. From: BOB DIAMOND                                           Time: 09:12 am
  15487.   To: ALL                                                   (Read 86 times)
  15488. Subj: MOVING TO TURBO C++
  15489.  
  15490. I'm considering the upgrade from Turbo C 2.0 to the C++ system.  The
  15491. software is retail at $ 149.00, but the street price is under $99.
  15492. Borland is offering an upgrade price of $79 plus S&H which is not much of
  15493. a discount.
  15494.  
  15495. Does anyone know if any of the major mail-order houses are authorized to
  15496. handle upgrades -- at below the Borland price?
  15497. ---------------
  15498. Following thread
  15499.  
  15500. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3A1Q2491 Date: 06/01/90
  15501. From: GRANT ELLSWORTH (Leader)                              Time: 09:41 pm
  15502.   To: BOB DIAMOND (Rcvd)                                    (Read 86 times)
  15503. Subj: R: MOVING TO TURBO C++
  15504.  
  15505. Bob, I've never known a mail-order outfit to undercut a software vendor's
  15506. best upgrade price to its registered paid-up customers.  Also, please note
  15507. that the "street price" does not include s+h.  Hence, I think the net
  15508. difference between the street price and BI's price will still be $20.  Now
  15509. there IS an advantage to going to BI for the upgrade ... BI will keep you
  15510. on its list of customers eligible for an upgrade at an upgrade price.
  15511.  
  15512. My inclination would be to go with the BI upgrade in spite of the wait.
  15513.  
  15514. Grant
  15515. ---------------
  15516. ** Current thread: MOVING TO TURBO C++
  15517.  
  15518. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3A210035 Date: 06/02/90
  15519. From: ROBERT BALSOVER                                       Time: 01:00 am
  15520.   To: BOB DIAMOND (Rcvd)                                    (Read 82 times)
  15521. Subj: R: MOVING TO TURBO C++
  15522.  
  15523. Bob,
  15524.      I'm going to take the opposite view from Grant, *if* you are only
  15525. updating TC 2.0 to TC++, go to your local software store and buy it.
  15526. The difference in price between Borland and the local Software ETC. is
  15527. only 5->10 dollars if you take S+H into account.  Just remeber to send in
  15528. your registration  card for TC++.  Borland underestimated the demand on a
  15529. TC->TC++ upgrade so there is a wait.  If you are going the TC Prof->TC++
  15530. Prof upgrade route, you should sit tight.  The stores don't have it yet
  15531. and the difference in price is much greater.
  15532. Bob
  15533. ---------------
  15534. ** Current thread: MOVING TO TURBO C++
  15535.  
  15536. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3A2D2496 Date: 06/02/90
  15537. From: GRANT ELLSWORTH (Leader)                              Time: 09:41 am
  15538.   To: ROBERT BALSOVER (Rcvd)                                (Read 84 times)
  15539. Subj: R: MOVING TO TURBO C++
  15540.  
  15541. Bob, Can you REALLY get a TC++ pkg for as low as about $110 at a retail
  15542. outlet?  If so, then I'd agree with you ---- if I were in a big hurry
  15543. to get the product.  What's the best walkin-retail price you've seen?
  15544. Regards, Grant
  15545. ---------------
  15546. ** Current thread: MOVING TO TURBO C++
  15547.  
  15548. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3A2P1335 Date: 06/02/90
  15549. From: ROBERT BALSOVER                                       Time: 08:22 pm
  15550.   To: GRANT ELLSWORTH (Rcvd)                                (Read 82 times)
  15551. Subj: R: MOVING TO TURBO C++
  15552.  
  15553. Grant,
  15554.      My friend only had TC 2.0, not the Professional package.  He said he
  15555. purchased his from Babbages for 5->10 over the official upgrade (plus s+h)
  15556. price.  If I were not waiting for TC++ Prof, I would have done the same.
  15557. Right now, Software etc. is having a special on TC++, I think its
  15558. somewhere between 100->105.
  15559. Bob
  15560. ---------------
  15561. ** Current thread: MOVING TO TURBO C++
  15562.  
  15563. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3A3Q2430 Date: 06/03/90
  15564. From: GRANT ELLSWORTH (Leader)                              Time: 09:40 pm
  15565.   To: ROBERT BALSOVER (Rcvd)                                (Read 83 times)
  15566. Subj: R: MOVING TO TURBO C++
  15567.  
  15568. Bob, I have a vague recollection that TC++ (not the PRO PAK) was being
  15569. offered by BI to the TC2.0 users at $79.  What's your understanding? Grant
  15570. ---------------
  15571. ** Current thread: MOVING TO TURBO C++
  15572.  
  15573. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3A412610 Date: 06/04/90
  15574. From: ROBERT BALSOVER                                       Time: 12:43 am
  15575.   To: GRANT ELLSWORTH (Rcvd)                                (Read 83 times)
  15576. Subj: R: MOVING TO TURBO C++
  15577.  
  15578. Grant,
  15579.      $79.95 is what is in the press release from Borland.  Someone in the
  15580. BROGB forem said that the got TC++ Prof from Computer Resellers for *LESS*
  15581. than what they would pay to Borland for the upgrade from TC Prof.  I am
  15582. going to call Computer Resellers tomorrow to se if it was B.S..  If not
  15583. B.S. I'll order from them instead and cancel my order with Borland.  He
  15584. also siad he got it in 2 days after the order.
  15585. Bob
  15586. ---------------
  15587. ** Current thread: MOVING TO TURBO C++
  15588.  
  15589. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3A4L0552 Date: 06/04/90
  15590. From: GRANT ELLSWORTH (Leader)                              Time: 05:09 pm
  15591.   To: ROBERT BALSOVER (Rcvd)                                (Read 86 times)
  15592. Subj: R: MOVING TO TURBO C++
  15593.  
  15594. Bob, Make sure that you're comparing apples and apples.  That is: Is the
  15595. price quoted as being less than BI's price for the TC++ PRO Upgrade a
  15596. price for TC++ ProPAk, or is it a price for TC++ by itself?  Seems to me
  15597. that the best street price for TC++ (no propak) should be less than the
  15598. BI price for the ProPAk "upgrade".   But, I'd be near shocked if the
  15599. best street price for the TC++ ProPak was less than the BI price for
  15600. the same thing to registered users.  Let us know what you come up with.
  15601.    Grant
  15602. ---------------
  15603. ** Current thread: MOVING TO TURBO C++
  15604.  
  15605. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3A5P0201 Date: 06/05/90
  15606. From: ROBERT BALSOVER                                       Time: 08:03 pm
  15607.   To: GRANT ELLSWORTH (Rcvd)                                (Read 82 times)
  15608. Subj: R: MOVING TO TURBO C++
  15609.  
  15610. Grant,
  15611. He didn't specify what he upgraded from, I'll be checking the price on it
  15612. from Computer Resellers as soon as I log off.  I'll let you know.
  15613. I did see TC++ Prof in a retail store today, $225 @ WaldenSoftware.
  15614. Bob
  15615. ---------------
  15616. ** Current thread: MOVING TO TURBO C++
  15617.  
  15618. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3A5R2720 Date: 06/05/90
  15619. From: ROBERT BALSOVER                                       Time: 10:45 pm
  15620.   To: GRANT ELLSWORTH (Rcvd)                                (Read 80 times)
  15621. Subj: R: MOVING TO TURBO C++
  15622.  
  15623. Grant,
  15624.      I can't find a ad for Computer Resellers, so I can't call them.
  15625. Someone in the BPROGB forem purchased from Programmers Conection.
  15626. He said it cost him $159 and that include overnight FedEX.
  15627. I'll call Borland tomorrow and if they haven't shipped mine yet I'll
  15628. cancel and order from the Programmers Connection.
  15629. Bob
  15630. ---------------
  15631. ** Current thread: MOVING TO TURBO C++
  15632.  
  15633. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AAM0967 Date: 06/06/90
  15634. From: GRANT ELLSWORTH (Leader)                              Time: 06:16 pm
  15635.   To: ROBERT BALSOVER (Rcvd)                                (Read 80 times)
  15636. Subj: R: MOVING TO TURBO C++
  15637.  
  15638. Bob, I've dealt with Programmers' Connection on several occaisions --- it
  15639. is a good outfit, indeed.  However, $30+ is a bit high of a price to pay
  15640. for impatience --- without compelling need.  Besides, there seems to be
  15641. other advantages to being on the vendor's "reliable loyal upgrading cus-
  15642. tomer" list ...  I'll wait for my copy.  Grant
  15643. ---------------
  15644. ** Current thread: MOVING TO TURBO C++
  15645.  
  15646. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AB11619 Date: 06/07/90
  15647. From: ROBERT BALSOVER                                       Time: 12:26 am
  15648.   To: GRANT ELLSWORTH (Rcvd)                                (Read 78 times)
  15649. Subj: R: MOVING TO TURBO C++
  15650.  
  15651. Grant,
  15652.      Thats your option.  I don't really think Borland cares where you get
  15653. it from anyway, why else would we see it in retail stores before *loyal*
  15654. upgrade customers recieve it.  I'd really like to know the advantages that
  15655. you refer to of being on the vendor's "reliable loyal upgrade customer"
  15656. list.  It Appears to me that Borland has demonstrated a lack of loyality
  15657. to us.  As long as we send in our registration card, we are all entitled
  15658. to the same service, no matter where you purchased it.
  15659. Bob
  15660. ---------------
  15661. ** Current thread: MOVING TO TURBO C++
  15662.  
  15663. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AC11384 Date: 06/08/90
  15664. From: ROBERT BALSOVER                                       Time: 12:23 am
  15665.   To: GRANT ELLSWORTH (Rcvd)                                (Read 80 times)
  15666. Subj: R: MOVING TO TURBO C++
  15667.  
  15668. Grant,
  15669.      I found out today why there might be a price difference.  Borland is
  15670. shipping their *loyal* customers a package without TASM manuals, all they
  15671. get is a .doc file listing the changes in TASM.
  15672.      I'm not sending this message to be a smart a**, I'd just like to put
  15673. my previous message in a more practical light.  And, to be fair,
  15674. Programmers Connection's price of $159 doesn't include UPS Blue label.
  15675. But,  it can be had a cheaper price from another mail order house.
  15676. Borland is a great company, but remember their company's business
  15677. policies are made by CPA's not the support staff.
  15678. Bob
  15679. ---------------
  15680. ** Current thread: MOVING TO TURBO C++
  15681.  
  15682. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3ACB2758 Date: 06/08/90
  15683. From: STEVEN KEY                                            Time: 07:45 am
  15684.   To: ROBERT BALSOVER (Rcvd)                                (Read 79 times)
  15685. Subj: R: MOVING TO TURBO C++
  15686.  
  15687. Bob,
  15688.  
  15689. I have been thinking about getting a copy of TC++, partly to get TASM and
  15690. the profiler to go with TP 5.5, and partly to start playing with C a bit.
  15691. Is the $159 the price for the whole package with C++, TASM, TD and the
  15692. profiler ( and ALL the manuals) ?
  15693.  
  15694. Steven
  15695. ---------------
  15696. ** Current thread: MOVING TO TURBO C++
  15697.  
  15698. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3ACP1215 Date: 06/08/90
  15699. From: GRANT ELLSWORTH (Leader)                              Time: 08:20 pm
  15700.   To: ROBERT BALSOVER (Rcvd)                                (Read 80 times)
  15701. Subj: R: MOVING TO TURBO C++
  15702.  
  15703. Bob, This debate is getting down to quibbling over the marginal issues.
  15704. Let's review a little of the bidding:
  15705.  
  15706.       Mail-Order       BI-Upgrade
  15707. Price:  $150 (best?)    $130      TC++ ProPak
  15708. Wait    3 da (avg)      25 da (Guess)
  15709. Manuals: ALL           Not All    based on your unconfirmed info
  15710.  
  15711. And let's add in the "informed early" factor ... Looks like this TC++ case
  15712. is one where the registered user base was not informed early and given a
  15713. jump on the distribution channels ... So, ...
  15714.  
  15715. Informed?  B4 Release(?) On Release
  15716.  
  15717. Net effect: (You're right) an irritating wash!
  15718.  
  15719. The margins are: 3 vs 25 days to wait and the possible absence of a manual
  15720. whose use may be questionable --- at the cost of $20.  That's about the
  15721. cost of 1 Week of cheap lunches or 2 days of moderate lunches.
  15722.  
  15723. Conclusion:  If you can skip lunch, have time to dinker with it now, and
  15724. want a full complement of docs, go for the mail order.  Otherwise, wait
  15725. one month at $1/da.
  15726.  
  15727. My experience with 5 yrs of buying stuff at BI's special intro prices has
  15728. been that in most cases, not all, I have been informed by mail of the
  15729. special upgrade offers BEFORE the product hit the street.  TC++ is the
  15730. most memorable, but not the only, exception.  Grant
  15731. ---------------
  15732. ** Current thread: MOVING TO TURBO C++
  15733.  
  15734. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AD11536 Date: 06/09/90
  15735. From: ROBERT BALSOVER                                       Time: 12:25 am
  15736.   To: STEVEN KEY (Rcvd)                                     (Read 77 times)
  15737. Subj: R: MOVING TO TURBO C++
  15738.  
  15739. yep, $159 (+S&H) gets the works.
  15740. ---------------
  15741. ** Current thread: MOVING TO TURBO C++
  15742.  
  15743. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AD12317 Date: 06/09/90
  15744. From: ROBERT BALSOVER                                       Time: 12:38 am
  15745.   To: GRANT ELLSWORTH (Rcvd)                                (Read 81 times)
  15746. Subj: R: MOVING TO TURBO C++
  15747.  
  15748. Grant,
  15749. You are right, this is a senseless debate.  A person should do as he
  15750. feels.
  15751. Happy trails
  15752. Bob
  15753. ---------------
  15754. ** Current thread: MOVING TO TURBO C++
  15755.  
  15756. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3ADE0479 Date: 06/09/90
  15757. From: GRANT ELLSWORTH (Leader)                              Time: 10:08 am
  15758.   To: ROBERT BALSOVER (Rcvd)                                (Read 78 times)
  15759. Subj: R: MOVING TO TURBO C++
  15760.  
  15761. Bob, Happy trails to you, too.  Grant
  15762. ---------------
  15763. ** Current thread: MOVING TO TURBO C++
  15764.  
  15765. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AEP2527 Date: 06/10/90
  15766. From: JIM MONROE                                            Time: 08:42 pm
  15767.   To: ROBERT BALSOVER (Rcvd)                                (Read 81 times)
  15768. Subj: R: MOVING TO TURBO C++
  15769.  
  15770. It seems that all of the arguing over price tag of the upgrade movement to
  15771. c++ or which ever route is available places price over function. If a
  15772. person needs or wants the item, go for it and not for the price tag. I
  15773. haver found that going directly to the source has produced my best results
  15774. over time. I am sure I could have saved a few hundred dollars through
  15775. shopping but I am not sure that it would have been worth the frustration.
  15776. While this is only my opinion, I would hope that we will see info on the
  15777. product and product application problems and solutions on the forum soon.
  15778. ---------------
  15779. ** Current thread: MOVING TO TURBO C++
  15780.  
  15781. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AFE1527 Date: 06/11/90
  15782. From: ROBERT BALSOVER                                       Time: 10:25 am
  15783.   To: JIM MONROE (Rcvd)                                     (Read 83 times)
  15784. Subj: R: MOVING TO TURBO C++
  15785.  
  15786. Jim,
  15787.      I have the compiler now and its worked fine so far.  I was
  15788. disapointed that td286 required 640k of extended memory to function, the
  15789. first press release on TD and Tools stated it only required 384k of
  15790. extended memory to function, which is what I have.  Turbo Profiles is
  15791. GREAT!  The new IDE is nice, but takes a little tim to get used to because
  15792. there are some differences between keystokes in it and the old IDE.
  15793.      Jim, actually Grant and I were not arguing about price, it was the
  15794. principle of what Borland was doing.  They pulled a very MS kind of stunt
  15795. and are getting a lot of heat from users in the forem on CIS.  The said it
  15796. was *not* a upgrade but a special offer, then they leave out the manuals,
  15797. they also dumped all availible product on retail stores and made the
  15798. *loyal* user cool his heels.  No Jim, price was not the issue.  If they
  15799. offered the same price or even $20 more for the TC++ Prof package,
  15800. including all manuals and didn't make the *loyal* user wait while the guy
  15801. on the street picked it up and Software ETC., I think there would have
  15802. been no problem.
  15803. Bob
  15804. ---------------
  15805. ** Current thread: MOVING TO TURBO C++
  15806.  
  15807. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AFN0596 Date: 06/11/90
  15808. From: JIM MONROE                                            Time: 07:09 pm
  15809.   To: ROBERT BALSOVER (Rcvd)                                (Read 82 times)
  15810. Subj: R: MOVING TO TURBO C++
  15811.  
  15812. It seems that all ro at least most of the software houses have gotten to
  15813. the point of ignoring the customer.  This seems like the attitude of the
  15814. Big computer manufacture of old. What is good for xxx is good for you the
  15815. customer, you (the customer are just to dumb to understand) just need
  15816. additional training.
  15817. Will you be able to make the Users Group this week?
  15818. ---------------
  15819. ** Current thread: MOVING TO TURBO C++
  15820.  
  15821. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AFN1922 Date: 06/11/90
  15822. From: ROBERT BALSOVER                                       Time: 07:32 pm
  15823.   To: JIM MONROE (Rcvd)                                     (Read 80 times)
  15824. Subj: R: MOVING TO TURBO C++
  15825.  
  15826. Jim,
  15827. When and where will the meeting be?
  15828. Bob
  15829. ---------------
  15830. ** Current thread: MOVING TO TURBO C++
  15831.  
  15832. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AGP2415 Date: 06/12/90
  15833. From: GRANT ELLSWORTH (Leader)                              Time: 08:40 pm
  15834.   To: ROBERT BALSOVER (Rcvd)                                (Read 77 times)
  15835. Subj: R: MOVING TO TURBO C++
  15836.  
  15837. Bob, re: td286(? -> not td386?) and 640K extended memory ...
  15838. That's the 1st i've heard about that.  Could you be doing something awry
  15839. in your setup or configuration stuff such that your triggering more
  15840. memory use than absolutely necessary?  Grant
  15841. ---------------
  15842. ** Current thread: MOVING TO TURBO C++
  15843.  
  15844. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AIS2905 Date: 06/14/90
  15845. From: ROBERT BALSOVER                                       Time: 11:48 pm
  15846.   To: GRANT ELLSWORTH (Rcvd)                                (Read 75 times)
  15847. Subj: R: MOVING TO TURBO C++
  15848.  
  15849. Grant,
  15850.      It reports that when I try to run it, then it aborts.  I don't even
  15851. get into the opening screen of TD286.  I believe it also says 640k
  15852. extended memory is required in the manuals.
  15853. Bob
  15854. ---------------
  15855. ** Current thread: MOVING TO TURBO C++
  15856.  
  15857. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AJR2180 Date: 06/15/90
  15858. From: GRANT ELLSWORTH (Leader)                              Time: 10:36 pm
  15859.   To: ROBERT BALSOVER (Rcvd)                                (Read 71 times)
  15860. Subj: R: MOVING TO TURBO C++
  15861.  
  15862. 640K EXTENDED memory???!!!!???  That's an unusual amount of EXTENDED
  15863. memory for a DOS-based program  to be asking for.  Are you SURE it said
  15864. EXTENDED, not EXPANDED??   What if you had an EMS driver, or a 386 + much
  15865. extra extended memory + qemm (or similar ems driver)???    What you report
  15866. is a little baffling.  Grant
  15867. ---------------
  15868. ** Current thread: MOVING TO TURBO C++
  15869.  
  15870. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AK12584 Date: 06/16/90
  15871. From: ROBERT BALSOVER                                       Time: 01:43 am
  15872.   To: GRANT ELLSWORTH (Rcvd)                                (Read 74 times)
  15873. Subj: R: MOVING TO TURBO C++
  15874.  
  15875. Grant,
  15876.      I always get extended and expanded mixed up, let me state another
  15877. way.  The memory above 1 meg that needs the processor to run in protected
  15878. mode.  Part of the problem maybe that Borland is using the TurboDrive(TM)
  15879. to operate in protected mode, it may not be common knowledge but they
  15880. licenced Eclipse's 286 Dos extender for their TurboDrive.  Eclipse does
  15881. not support virtual memory for data segements like their 386 extender
  15882. does, the removed it due to problems they were having.  I found this out
  15883. when I called Eclipse about the add in the Programmers Connection,
  15884. Programmers Connection is selling a special TC only version if their 286
  15885. extender cheap.  Anyway, TD286 may need the memory for its own data.
  15886. Thats my best guess.
  15887. Bob
  15888. ---------------
  15889. ** Current thread: MOVING TO TURBO C++
  15890.  
  15891. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AMP0540 Date: 06/18/90
  15892. From: JIM MONROE                                            Time: 08:09 pm
  15893.   To: ROBERT BALSOVER (Rcvd)                                (Read 74 times)
  15894. Subj: R: MOVING TO TURBO C++
  15895.  
  15896. I am sorry that I did not get back to you on time, the meetings are held
  15897. the 2nd thursday and the 4th tuesday. They start at 7:00 P.M. and are held
  15898. at the old Allis Chalmers club house. It is now a resturant and I beleive
  15899. that it is called Sue and Shar's Southern Plantation.  The Tuesday meeting
  15900. will be a swap fest ( I think).  Try to come out and see if you are
  15901. interested in the group.
  15902. s
  15903. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  15904.  
  15905. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3A1P0947 Date: 06/01/90
  15906. From: OTTO PORTER                                           Time: 08:15 pm
  15907.   To: ALL                                                   (Read 83 times)
  15908. Subj: TURBOC COMM CODE
  15909.  
  15910. Can anyone point me at some source code for comm routines,
  15911. preferably in Turbo C.  I have downloaded the TCOMM lib
  15912. already and a couple of other small files with limited
  15913. source code ( serialtc.zip, autodile.zip ). There are
  15914. probably other, better examples that I missed.
  15915. ---------------
  15916. Following thread
  15917.  
  15918. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AFN2200 Date: 06/11/90
  15919. From: ROBERT BALSOVER                                       Time: 07:36 pm
  15920.   To: JIM MONROE (Rcvd)                                     (Read 77 times)
  15921. Subj: R: TURBOC COMM CODE
  15922.  
  15923. Jim
  15924. Be careful with the source from that book,  it has a lot of errors
  15925. reported using TC in the large memory model.  I don't think he tested the
  15926. source in anything other than the small model.
  15927. Bob
  15928. ---------------
  15929. ** Current thread: TURBOC COMM CODE
  15930.  
  15931. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AKR2950 Date: 06/16/90
  15932. From: OTTO PORTER                                           Time: 10:49 pm
  15933.   To: JIM MONROE (Rcvd)                                     (Read 72 times)
  15934. Subj: R: TURBOC COMM CODE
  15935.  
  15936. Thanks for the suggestion.  I remember reading a review of this book
  15937. sometime ago and thought that it would be worthwhile.
  15938.  
  15939. Otto
  15940. ---------------
  15941. ** Current thread: TURBOC COMM CODE
  15942.  
  15943. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AMP0677 Date: 06/18/90
  15944. From: JIM MONROE                                            Time: 08:11 pm
  15945.   To: ROBERT BALSOVER (Rcvd)                                (Read 73 times)
  15946. Subj: R: TURBOC COMM CODE
  15947.  
  15948. I have not entered that much of it, I am using the MIX compiler and note
  15949. that a number of changes must be made. I wish that the books that are in
  15950. the market would be more carefully reviewed. I have the same problems with
  15951. text books. I teach accounting on a part time basis and find it quite
  15952. frustrating when the text has an error in a problem that I am attempting
  15953. to demonstrate.
  15954. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  15955.  
  15956. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AAM1285 Date: 06/06/90
  15957. From: GRANT ELLSWORTH (Leader)                              Time: 06:21 pm
  15958.   To: SCOTT CHAMBERLAIN (Rcvd)                              (Read 74 times)
  15959. Subj: FPRINTF() RESOLVED?
  15960.  
  15961. Scott, Did you ever resolve your fprintf() anomaly?  Haven't seen your
  15962. ppn since I suggested writing to a file and/or file upload for diags.
  15963. Hope all is well!  Grant
  15964. ---------------
  15965. Following thread
  15966.  
  15967. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3ABC2488 Date: 06/07/90
  15968. From: SCOTT CHAMBERLAIN                                     Time: 08:41 am
  15969.   To: GRANT ELLSWORTH (Rcvd)                                (Read 74 times)
  15970. Subj: R: FPRINTF() RESOLVED?
  15971.  
  15972. I've got a version of the program printing correctly, and now I have been
  15973. dealing with a new general manager who wants instant answers to non-
  15974. deterministic problems.
  15975.  
  15976. Once I get past the problem of leading the horse to the workstation, and
  15977. forcing him to drink, then I can get back to the pleasant halcyon days of
  15978. working with software instead of dealing with insensitive, mulish human
  15979. beings.
  15980.  
  15981. Later,
  15982.    Scott
  15983. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  15984.  
  15985. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3ABE1569 Date: 06/07/90
  15986. From: GREGORY WILSON                                        Time: 10:26 am
  15987.   To: ALL                                                   (Read 81 times)
  15988. Subj: SIMPLE 'C' QUESTION
  15989.  
  15990. What is the difference between the following two programs?:
  15991.  
  15992. -----------------------------------------------------
  15993. #include<stdio.h>
  15994.  
  15995. int a,b,c;
  15996.  
  15997. main()
  15998. {
  15999.     puts("Hello");
  16000. }
  16001. ------------------------------------------------------
  16002. #include<stdio.h>
  16003.  
  16004. static int a,b,c;
  16005.  
  16006. main()
  16007. {
  16008.     puts("Hello");
  16009. }
  16010. ------------------------------------------------------
  16011.  
  16012. Does 'static' have any effect since these vars are external?
  16013.  
  16014. Thanks!
  16015. Gregory Wilson
  16016. ---------------
  16017. Following thread
  16018.  
  16019. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AHE1649 Date: 06/13/90
  16020. From: THOMAS ZERUCHA                                        Time: 10:27 am
  16021.   To: GREGORY WILSON (Rcvd)                                 (Read 72 times)
  16022. Subj: R: SIMPLE 'C' QUESTION
  16023.  
  16024. static when applied to something otherwise global makes it local to that
  16025. module (i.e. the portion of the program in the particular file).
  16026. So, in the first case (no static), a,b, and c would be visible from
  16027. another module that externed them.  In the second case, they would not be
  16028. visible to any other modules.
  16029.   So in that context, static means "local".  This applies to functions as
  16030. well as variables.  The other context is similar, inside a function, where
  16031. static makes the variable (already local to the function) "global" in the
  16032. sense that it does not change between invocations of the function - but it
  16033. is still hidden (this is known as scoping as in the "scope" of a
  16034. definition).
  16035. ---------------
  16036. ** Current thread: SIMPLE 'C' QUESTION
  16037.  
  16038. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AHI1793 Date: 06/13/90
  16039. From: GREGORY WILSON                                        Time: 02:29 pm
  16040.   To: THOMAS ZERUCHA (Rcvd)                                 (Read 70 times)
  16041. Subj: R: SIMPLE 'C' QUESTION
  16042.  
  16043. Thanks for clearing it up for me! Makes sense!
  16044. Gregory Wilson
  16045. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  16046.  
  16047. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3ABE1824 Date: 06/07/90
  16048. From: GREGORY WILSON                                        Time: 10:30 am
  16049.   To: ALL                                                   (Read 76 times)
  16050. Subj: POINTERS TO STRINGS
  16051.  
  16052. Can anyone give me a simple example of the following:
  16053.  
  16054.    I need an array of strings that can contain a maximum of 80
  16055.    characters. I will load the arrays using 'strcpy'. The
  16056.    array should be able to hold up to 200 lines. I need to do
  16057.    this using pointers because there is a function that I want
  16058.    to use that requires that the address of an array of
  16059.    pointers to the strings be passed to it.
  16060.  
  16061. Any help would be greatly appreciated!
  16062.  
  16063. Thanks,
  16064. Gregory Wilson
  16065. ---------------
  16066. Following thread
  16067.  
  16068. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AC11771 Date: 06/08/90
  16069. From: ROBERT BALSOVER                                       Time: 12:29 am
  16070.   To: GREGORY WILSON (Rcvd)                                 (Read 77 times)
  16071. Subj: R: POINTERS TO STRINGS
  16072.  
  16073. Gregory,
  16074.      How about:
  16075. char *strarray[200];
  16076. .
  16077. As you initialize the strings, you can allocate them using malloc() or
  16078. calloc().  This would also remove the  fixed string size.
  16079. Declared this way, it means a array of 200 char pointers.
  16080. Bob
  16081. ---------------
  16082. ** Current thread: POINTERS TO STRINGS
  16083.  
  16084. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3ACN3291 Date: 06/08/90
  16085. From: GREGORY WILSON                                        Time: 07:54 pm
  16086.   To: ROBERT BALSOVER (Rcvd)                                (Read 74 times)
  16087. Subj: R: POINTERS TO STRINGS
  16088.  
  16089.  RB>      How about:
  16090.  RB> char *strarray[200];
  16091.  RB> .
  16092.  RB> As you initialize the strings, you can allocate them using
  16093.  RB> malloc() or calloc().  This would also remove the  fixed
  16094.  RB> string size. Declared this way, it means a array of 200 char
  16095.  RB> pointers.
  16096.  
  16097. Do I have to do a malloc for each string or is this a good place for
  16098. calloc. If I have to do it for each string, won't it take longer. The way
  16099. I solved my problem for now is to use a regular character 2 dim. array and
  16100. then build an array of pointers by something like:
  16101.  
  16102. char *winptr[200];
  16103.         for(x=0;x<=i;++x) winptr[x] = &winarray[x][0];
  16104.  
  16105. Is this ok? It works and all but is there a better way? I then pass the
  16106. var 'winptr' to the function that requires an array of pointers to
  16107. strings (CXL WPICKSTR function).
  16108. Anyway, I appreciate your help!!!
  16109. Gregory Wilson
  16110. ---------------
  16111. ** Current thread: POINTERS TO STRINGS
  16112.  
  16113. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AD11872 Date: 06/09/90
  16114. From: ROBERT BALSOVER                                       Time: 12:31 am
  16115.   To: GREGORY WILSON (Rcvd)                                 (Read 75 times)
  16116. Subj: R: POINTERS TO STRINGS
  16117.  
  16118. Gregory,
  16119. Using calloc() would be safer, you'd know for a fact that the string was
  16120. null terminated.
  16121. Bob
  16122. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  16123.  
  16124. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3ABE1888 Date: 06/07/90
  16125. From: GREGORY WILSON                                        Time: 10:31 am
  16126.   To: ALL                                                   (Read 77 times)
  16127. Subj: MIX POWER C VS MSC
  16128.  
  16129. Has anyone out there compared Microsoft 'C' 5.1/6.0 to Mix Power 'C'. How
  16130. did it compare? Speed? Size? Compatibility?
  16131. Thanks!
  16132. Gregory Wilson
  16133. ---------------
  16134. Following thread
  16135.  
  16136. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3ACP1749 Date: 06/08/90
  16137. From: GRANT ELLSWORTH (Leader)                              Time: 08:29 pm
  16138.   To: GREGORY WILSON (Rcvd)                                 (Read 75 times)
  16139. Subj: R: MIX POWER C VS MSC
  16140.  
  16141. I saw a review some months back which included Mix Power C and M$C 5.1
  16142. (among others like TC2.01) ...
  16143.  
  16144. In all the aspects you listed (speed of .exe, size of .exe), M$C was way
  16145. ahead.  Power C does seem to have a large degree of source compatibility
  16146. with M$C.  However, considering the "reliabilty" of compiled results, and
  16147. other "quality" factors, Power C may be ahead === way ahead.  I have not
  16148. experimented much with my copy and can't make any strong claims.  Grant
  16149. ---------------
  16150. ** Current thread: MIX POWER C VS MSC
  16151.  
  16152. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3ACR3448 Date: 06/08/90
  16153. From: GREGORY WILSON                                        Time: 10:57 pm
  16154.   To: GRANT ELLSWORTH (Rcvd)                                (Read 75 times)
  16155. Subj: R: MIX POWER C VS MSC
  16156.  
  16157. Thanks. I guess for $19.95, I almost have to get it. A friend of mine said
  16158. that I should also get the debugger (also $19.95). It is suppose to be
  16159. superior to Codeview. I do like the debugger in the new QuickC 2.5 however
  16160. and will probably stick to that and MSC.
  16161. Anyway,
  16162. Thanks!!!
  16163. Gregory Wilson
  16164. ---------------
  16165. ** Current thread: MIX POWER C VS MSC
  16166.  
  16167. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3ADK0471 Date: 06/09/90
  16168. From: GRANT ELLSWORTH (Leader)                              Time: 04:07 pm
  16169.   To: GREGORY WILSON (Rcvd)                                 (Read 78 times)
  16170. Subj: R: MIX POWER C VS MSC
  16171.  
  16172. Gregory, I purchased both the compiler and the debugger to evaluate it as
  16173. a learning tool.  I was impressed.  It's well worth the $50 expense for
  16174. that purpose.  The POWERTRACE debugger and QC2.5's debugger may be equiv-
  16175. alent for your purposes.  The latest Borland TD2.0 release is supposedly
  16176. much better than the latest CodeView debugger and is CV/M$C compatible.
  16177. You might want to get it for use with your MSC programs.  Grant
  16178. ---------------
  16179. ** Current thread: MIX POWER C VS MSC
  16180.  
  16181. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3ADN2202 Date: 06/09/90
  16182. From: GREGORY WILSON                                        Time: 07:36 pm
  16183.   To: GRANT ELLSWORTH (Rcvd)                                (Read 80 times)
  16184. Subj: R: MIX POWER C VS MSC
  16185.  
  16186. Thanks for the info! I guess I will be getting the compiler since
  16187. the price is so nice. I like trying new things so another toy won't
  16188. hurt too bad at that price. I did not know about the new TD.
  16189. Thanks again,
  16190. Gregory Wilson
  16191.  
  16192. ---------------
  16193. ** Current thread: MIX POWER C VS MSC
  16194.  
  16195. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AHE1984 Date: 06/13/90
  16196. From: THOMAS ZERUCHA                                        Time: 10:33 am
  16197.   To: GREGORY WILSON (Rcvd)                                 (Read 71 times)
  16198. Subj: R: MIX POWER C VS MSC
  16199.  
  16200. Be sure to get the debugger.  I use Power C for all my small programs (I
  16201. may recompile them later).  The debugger doesn't have a lot of bells and
  16202. whistles, but makes the operation of the program very clear, especially
  16203. since you can watch your variables change (this can be done in other
  16204. debuggers, but you need to set up a window to see them, then specify each
  16205. one - and most don't provide a list, so you have to remember the exact
  16206. name).  PowerCTrace has everything like a menu.
  16207.    I haven't found many bugs (as of 1.3 - there was a problem with leap
  16208. years we found in 1988, and be careful when comparing far pointers).  I
  16209. have produced production code with it, and for the price it is a steal.
  16210. ---------------
  16211. ** Current thread: MIX POWER C VS MSC
  16212.  
  16213. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AHI1873 Date: 06/13/90
  16214. From: GREGORY WILSON                                        Time: 02:31 pm
  16215.   To: THOMAS ZERUCHA (Rcvd)                                 (Read 71 times)
  16216. Subj: R: MIX POWER C VS MSC
  16217.  
  16218. I just ordered POWERC with the Debugger. FOr the price, I have to try it!
  16219. Thanks again!
  16220. Gregory Wilson
  16221. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  16222.  
  16223. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3ABH1069 Date: 06/07/90
  16224. From: DAVID ABBOTT                                          Time: 01:17 pm
  16225.   To: ALL                                                   (Read 78 times)
  16226. Subj: IDEAS PLEASE
  16227.  
  16228. I am looking for a way to stuff the dos keyboard buffer.  Similar to
  16229. ungetch (), but i would like to unget_a_string ();  I'm using turboc 2.0
  16230. if that matters?  Anyone have any sample coding ideas they could share?
  16231.  
  16232. Thanks, David Abbott
  16233. ---------------
  16234. Following thread
  16235.  
  16236. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AC11980 Date: 06/08/90
  16237. From: ROBERT BALSOVER                                       Time: 12:33 am
  16238.   To: DAVID ABBOTT (Rcvd)                                   (Read 76 times)
  16239. Subj: R: IDEAS PLEASE
  16240.  
  16241. David,
  16242.      Use ungetch().  start with a '\r' (I think, but it could be '\n',
  16243. experiment with it) then from the last char of the string to the first,
  16244. ungetch() them.  DOS has a 128 keyboard buffer so I think that length is
  16245. the limit.
  16246. Bob
  16247. ---------------
  16248. ** Current thread: IDEAS PLEASE
  16249.  
  16250. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3ACB2502 Date: 06/08/90
  16251. From: STEVEN KEY                                            Time: 07:41 am
  16252.   To: ROBERT BALSOVER (Rcvd)                                (Read 74 times)
  16253. Subj: R: IDEAS PLEASE
  16254.  
  16255. Bob,
  16256.  
  16257. I'm not a C'er, so I don't know exactly how unget works, but I do know how
  16258. to stuff keys into the Bios buffer.  If unget is putting things in  the
  16259. buffer that the low numbered DOS calls get things from, the limit is 16
  16260. chars - the buffer has 32 bytes and each keystroke leaves a scan code and
  16261. either 0 or ASCII for the key.  DOS has a limit of 128 chars on the
  16262. command line.  Does unget deal with the command line passed into the
  16263. program in the Program Segment Prefix ?
  16264.  
  16265. steven
  16266. ---------------
  16267. ** Current thread: IDEAS PLEASE
  16268.  
  16269. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3ACE3151 Date: 06/08/90
  16270. From: DAVID ABBOTT                                          Time: 10:52 am
  16271.   To: ROBERT BALSOVER (Rcvd)                                (Read 76 times)
  16272. Subj: R: IDEAS PLEASE
  16273.  
  16274. Bob,
  16275.   thanks for the quick response.  I have not tried it yet, but do believe
  16276. it will fail.  the documentation states that a subsequent call to
  16277. ungetch () prior to a getch () will result in an error.  There has to be
  16278. be a way... Any other ideas???
  16279. ---------------
  16280. ** Current thread: IDEAS PLEASE
  16281.  
  16282. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AD11473 Date: 06/09/90
  16283. From: ROBERT BALSOVER                                       Time: 12:24 am
  16284.   To: STEVEN KEY (Rcvd)                                     (Read 74 times)
  16285. Subj: R: IDEAS PLEASE
  16286.  
  16287. Steven,
  16288. You're probably correct.  I thought it was 128 for the bios buffer, but
  16289. why don't you try it. (it couldn't hurt)
  16290. Bob
  16291. ---------------
  16292. ** Current thread: IDEAS PLEASE
  16293.  
  16294. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AD11636 Date: 06/09/90
  16295. From: ROBERT BALSOVER                                       Time: 12:27 am
  16296.   To: DAVID ABBOTT (Rcvd)                                   (Read 75 times)
  16297. Subj: R: IDEAS PLEASE
  16298.  
  16299. David,
  16300. I haven't needed something like that before, so I can't help you.  It
  16301. might not hurt to try it anyway.
  16302. Bob
  16303. ---------------
  16304. ** Current thread: IDEAS PLEASE
  16305.  
  16306. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AD11751 Date: 06/09/90
  16307. From: ROBERT BALSOVER                                       Time: 12:29 am
  16308.   To: DAVID ABBOTT (Rcvd)                                   (Read 76 times)
  16309. Subj: R: IDEAS PLEASE
  16310.  
  16311. David,
  16312. It occurred to mee that it might be the limitation of the C library,
  16313. ungetch() might not stuff the keyboard buffer, just the buffer in the C
  16314. library.  Try to go direct to the buffer itself.
  16315. Bob
  16316. ---------------
  16317. ** Current thread: IDEAS PLEASE
  16318.  
  16319. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AEP2142 Date: 06/10/90
  16320. From: JIM MONROE                                            Time: 08:35 pm
  16321.   To: ROBERT BALSOVER (Rcvd)                                (Read 78 times)
  16322. Subj: R: IDEAS PLEASE
  16323.  
  16324. I think by looking at the Assb code for the functions, it will be possible
  16325. to decipher the problem.  I have not done that particular task yet but the
  16326. assb code usually halps me clear up the uniquie problems that I getOp hung
  16327. up on.
  16328. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  16329.  
  16330. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3ACQ3197 Date: 06/08/90
  16331. From: CRAIG SMITH                                           Time: 09:53 pm
  16332.   To: ALL                                                   (Read 75 times)
  16333. Subj: C COMMUNICATIONS
  16334.  
  16335. I am looking for any recommendations for MSC libraries for interrupt
  16336. driven communcations.  Anyone like a particular commercial or shareware
  16337. package?
  16338. ---------------
  16339. Following thread
  16340.  
  16341. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AF11330 Date: 06/11/90
  16342. From: RON FOX                                               Time: 01:22 am
  16343.   To: CRAIG SMITH (Rcvd)                                    (Read 79 times)
  16344. Subj: R: C COMMUNICATIONS
  16345.  
  16346. Craig,
  16347. I have been using the South Mountain Software Essential Comm package for a
  16348. couple of years.  I like it, although it does have keyboard and timer
  16349. services built in.  they can be removed by modifying the source.  I think
  16350. that it is pretty easy to use.  I got a communications interface completed
  16351. in less than three days, it was a pretty simple one.  I had the Asymc
  16352. package from Blaise for Turbo Pascal about four years ago and had enough
  16353. problems with it that I did not get the C version.
  16354. I don't know about any other packages and have not seen a review lately.
  16355. Ron
  16356. ---------------
  16357. ** Current thread: C COMMUNICATIONS
  16358.  
  16359. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AFJ2926 Date: 06/11/90
  16360. From: CRAIG SMITH                                           Time: 03:48 pm
  16361.   To: RON FOX (Rcvd)                                        (Read 80 times)
  16362. Subj: R: C COMMUNICATIONS
  16363.  
  16364. Thanks for the info.  I appreciate your recommendation, but South
  16365. Mountain's package is a bit pricey ($300+).  But then again, your
  16366. experience with the Blaise product may show that there is more to cost
  16367. than just the up-front price...
  16368. ---------------
  16369. ** Current thread: C COMMUNICATIONS
  16370.  
  16371. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AGR2748 Date: 06/12/90
  16372. From: RON FOX                                               Time: 10:45 pm
  16373.   To: CRAIG SMITH (Rcvd)                                    (Read 71 times)
  16374. Subj: R: C COMMUNICATIONS
  16375.  
  16376. I agree that the South Mountain stuff is expensive.  When I bought the
  16377. package I think that it was in the $150 range.  It was about a year ago
  16378. that they raised their prices.  They dis add drivers for the digiboard and
  16379. a number of other boards.  They also increased the supported speed to 115k
  16380. baud.
  16381. Ron
  16382. ---------------
  16383. ** Current thread: C COMMUNICATIONS
  16384.  
  16385. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AHE1360 Date: 06/13/90
  16386. From: THOMAS ZERUCHA                                        Time: 10:22 am
  16387.   To: CRAIG SMITH (Rcvd)                                    (Read 69 times)
  16388. Subj: R: C COMMUNICATIONS
  16389.  
  16390. You may also want to look at C Communications Toolkit from Magna Carta
  16391. (they are in Texas).  $149 retail, less mail order.  It has lots of nice
  16392. things (direct modem support, 16550 and other chips, buffered and
  16393. interrupts handled).  Full source is included.  One warning: it is 1.0 now
  16394. and may have a few bugs (I found two, but with the source it was simple to
  16395. find them and they are corrected now).
  16396. ---------------
  16397. ** Current thread: C COMMUNICATIONS
  16398.  
  16399. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AIE0841 Date: 06/14/90
  16400. From: CRAIG SMITH                                           Time: 10:14 am
  16401.   To: RON FOX (Rcvd)                                        (Read 70 times)
  16402. Subj: R: C COMMUNICATIONS
  16403.  
  16404. One other problem I have with South Mountain (formerly Essential Software)
  16405. is their upgrade policy.  They wanted more to upgrade their C Utility
  16406. Library than I originally paid for it.  Granted, the new version added a
  16407. few things, but not nearly enough to justify the upgrade price.  I don't
  16408. need that kind of support...
  16409.  
  16410.  
  16411.  
  16412.  
  16413. C
  16414. > Pausing after each message is now ON
  16415. > The current message will now be re-displayed
  16416. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AIE0841 Date: 06/14/90
  16417. From: CRAIG SMITH                                           Time: 10:14 am
  16418.   To: RON FOX (Rcvd)                                        (Read 71 times)
  16419. Subj: R: C COMMUNICATIONS
  16420.  
  16421. One other problem I have with South Mountain (formerly Essential Software)
  16422. is their upgrade policy.  They wanted more to upgrade their C Utility
  16423. Library than I originally paid for it.  Granted, the new version added a
  16424. few things, but not nearly enough to justify the upgrade price.  I don't
  16425. need that kind of support...
  16426. ---------------
  16427. ** Current thread: C COMMUNICATIONS
  16428. [N]xt (B)ack (L)st (R)ply (P)riv (C)ntuos (T)hrd (A)brt (?=HELP)-> B
  16429.  
  16430. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AHE1360 Date: 06/13/90
  16431. From: THOMAS ZERUCHA                                        Time: 10:22 am
  16432.   To: CRAIG SMITH (Rcvd)                                    (Read 70 times)
  16433. Subj: R: C COMMUNICATIONS
  16434.  
  16435. You may also want to look at C Communications Toolkit from Magna Carta
  16436. (they are in Texas).  $149 retail, less mail order.  It has lots of nice
  16437. things (direct modem support, 16550 and other chips, buffered and
  16438. interrupts handled).  Full source is included.  One warning: it is 1.0 now
  16439. and may have a few bugs (I found two, but with the source it was simple to
  16440. find them and they are corrected now).
  16441. ---------------
  16442. ** Current thread: C COMMUNICATIONS
  16443. [N]xt (B)ack (L)st (R)ply (P)riv (C)ntuos (T)hrd (A)brt (?=HELP)-> ?
  16444.  
  16445. ----------
  16446. N (Next): Select "N" (no quotes) to read the next message.  If you're
  16447. currently following a thread, the next message in that thread will display.
  16448. Otherwise, the message immediately following your current message will
  16449. display.
  16450.  
  16451. ----------
  16452. B (Backward): Select "B" (no quotes) to read the previous message.
  16453.  
  16454. ----------
  16455. D (Delete):  Select "D" (no quotes) to delete the current message.  If the
  16456. message is marked and the person it is to hasn't read it, it will
  16457. automatically be unmarked.  After deleting messages, the system automatically
  16458. goes to the next message.  If you're reading a thread, the next message will
  16459. be the next message in the thread.  If you didn't write the current message
  16460. and the message isn't to you, the system will not allow you to delete it.
  16461.  
  16462. ----------
  16463. L (List): Select "L" to list the current message again.
  16464.  
  16465. ----------
  16466. >> More? ([Y]/Stop/Continuous/) 
  16467. >>> Inactivity warning:  One minute to automatic logoff!
  16468.  
  16469. >>> Inactivity limit exceeded:  Automatic logoff initiated.
  16470.  
  16471. Countdown to automatic log-off (press ENTER to abort)  1  seconds
  16472.  
  16473.  
  16474. Thank you for visiting Exec-PC, Gary
  16475.  
  16476. Time on the system this logon:  72 minutes
  16477.        Time left for the week:  222 minutes
  16478.  
  16479.  
  16480.  
  16481.  
  16482. .D/àAª7┼└▒1┘Z>ü£^X╧[├s╜æiM╧?░7M╣╔σπî╒╠Ω'▄¬ñ╙ÆsûQç7àY╔F╬ü║ëE≥╖k┴¡≤Å┘∞JMo =≤τQ4Γg╬bc«1Ö"ê╢╘≥º1╫╔9h7t■äEK▐8«wOJΩ<û╞┼╗½u¼╟┘╠x╘Σ¥┼6é¢9áyφ┐╥τC*■Hπ
  16483. t°QUMσôΩ┐¼δ┘┴╝ZîQ}á{i¿3Ü]rÄ├σ
  16484. k    ë║dê&pâ K±çÇy¡ç┼Ö─f+Gd₧ÇP[à╚ù)πp²$MédÑ┐=w┬∙QOUx}4ⁿÆ9A∩µÆ▌¡6T*>{7½σ
  16485. yB▓ÄB«²ìæÜ·╪0HπΦ|HB5¬l┌╟+ªÜ@~>CÑäT⌠F≤JvGÄ∩0ƒÅ╪n░
  16486. δ┼α<¬∞í╪ä}"φ" «<┘╠x<╖┬áä±âY╦┴Æ@₧;╠±├W┐i╫<╧ε┤)πöBVR/N│₧Xτñ∩═áåⁿO╩Çñ│L¡êπî½ü.┌J⌠FO∙«lJ
  16487.  
  16488. P to pause, S to cancel output
  16489. ------------------------------
  16490.  
  16491. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3ACQ3197 Date: 06/08/90
  16492. From: CRAIG SMITH                                           Time: 09:53 pm
  16493.   To: ALL                                                   (Read 76 times)
  16494. Subj: C COMMUNICATIONS
  16495.  
  16496. I am looking for any recommendations for MSC libraries for interrupt
  16497. driven communcations.  Anyone like a particular commercial or shareware
  16498. package?
  16499. ---------------
  16500. Following thread
  16501.  
  16502. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AF11330 Date: 06/11/90
  16503. From: RON FOX                                               Time: 01:22 am
  16504.   To: CRAIG SMITH (Rcvd)                                    (Read 80 times)
  16505. Subj: R: C COMMUNICATIONS
  16506.  
  16507. Craig,
  16508. I have been using the South Mountain Software Essential Comm package for a
  16509. couple of years.  I like it, although it does have keyboard and timer
  16510. services built in.  they can be removed by modifying the source.  I think
  16511. that it is pretty easy to use.  I got a communications interface completed
  16512. in less than three days, it was a pretty simple one.  I had the Asymc
  16513. package from Blaise for Turbo Pascal about four years ago and had enough
  16514. problems with it that I did not get the C version.
  16515. I don't know about any other packages and have not seen a review lately.
  16516. Ron
  16517. ---------------
  16518. ** Current thread: C COMMUNICATIONS
  16519.  
  16520. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AFJ2926 Date: 06/11/90
  16521. From: CRAIG SMITH                                           Time: 03:48 pm
  16522.   To: RON FOX (Rcvd)                                        (Read 81 times)
  16523. Subj: R: C COMMUNICATIONS
  16524.  
  16525. Thanks for the info.  I appreciate your recommendation, but South
  16526. Mountain's package is a bit pricey ($300+).  But then again, your
  16527. experience with the Blaise product may show that there is more to cost
  16528. than just the up-front price...
  16529. ---------------
  16530. ** Current thread: C COMMUNICATIONS
  16531.  
  16532. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AGR2748 Date: 06/12/90
  16533. From: RON FOX                                               Time: 10:45 pm
  16534.   To: CRAIG SMITH (Rcvd)                                    (Read 72 times)
  16535. Subj: R: C COMMUNICATIONS
  16536.  
  16537. I agree that the South Mountain stuff is expensive.  When I bought the
  16538. package I think that it was in the $150 range.  It was about a year ago
  16539. that they raised their prices.  They dis add drivers for the digiboard and
  16540. a number of other boards.  They also increased the supported speed to 115k
  16541. baud.
  16542. Ron
  16543. ---------------
  16544. ** Current thread: C COMMUNICATIONS
  16545.  
  16546. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AHE1360 Date: 06/13/90
  16547. From: THOMAS ZERUCHA                                        Time: 10:22 am
  16548.   To: CRAIG SMITH (Rcvd)                                    (Read 71 times)
  16549. Subj: R: C COMMUNICATIONS
  16550.  
  16551. You may also want to look at C Communications Toolkit from Magna Carta
  16552. (they are in Texas).  $149 retail, less mail order.  It has lots of nice
  16553. things (direct modem support, 16550 and other chips, buffered and
  16554. interrupts handled).  Full source is included.  One warning: it is 1.0 now
  16555. and may have a few bugs (I found two, but with the source it was simple to
  16556. find them and they are corrected now).
  16557. ---------------
  16558. ** Current thread: C COMMUNICATIONS
  16559.  
  16560. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AIE0841 Date: 06/14/90
  16561. From: CRAIG SMITH                                           Time: 10:14 am
  16562.   To: RON FOX (Rcvd)                                        (Read 72 times)
  16563. Subj: R: C COMMUNICATIONS
  16564.  
  16565. One other problem I have with South Mountain (formerly Essential Software)
  16566. is their upgrade policy.  They wanted more to upgrade their C Utility
  16567. Library than I originally paid for it.  Granted, the new version added a
  16568. few things, but not nearly enough to justify the upgrade price.  I don't
  16569. need that kind of support...
  16570.  
  16571. ---------------
  16572. ** Current thread: C COMMUNICATIONS
  16573.  
  16574. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AIE1064 Date: 06/14/90
  16575. From: CRAIG SMITH                                           Time: 10:17 am
  16576.   To: THOMAS ZERUCHA (Rcvd)                                 (Read 71 times)
  16577. Subj: R: C COMMUNICATIONS
  16578.  
  16579. I noticed this product in the Programmer's Shop catalog.  It looks like a
  16580. pretty complete package at a very good price.  I hesitated only beause I
  16581. have not dealt with Magna Carta before.  Based on your recommendation (
  16582. and the reasonable price) I'll have to give it serious consideration.
  16583.  
  16584. ---------------
  16585. ** Current thread: C COMMUNICATIONS
  16586.  
  16587. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AJL2957 Date: 06/15/90
  16588. From: RON FOX                                               Time: 05:49 pm
  16589.   To: CRAIG SMITH (Rcvd)                                    (Read 72 times)
  16590. Subj: R: C COMMUNICATIONS
  16591.  
  16592. Craig,
  16593. I upgraded the c utility package, also.  I really didn't want to, but they
  16594. added shadowed windows.  I had rewritten the version 4 to do shadowed
  16595. windows, but it was hacked and I wanted a cleaner implementation.  I think
  16596. that they are putting their prices more inline with who they think taht
  16597. their competition is.  There are any number of compatable packages that
  16598. are priced in the South mountain range.  Considering that it took about
  16599. 1/3 the time to write a menu and form based database manager program using
  16600. the c_utility package than it took to write a compatable program using C
  16601. Worthy,  I really cannot complain about the price.
  16602. One thing to look for is that most packages rely on the compiler to
  16603. release unused memory to the operating system.  MSC, until V6.0 and
  16604. heapmin(), does not release memory well.  Consequently, the South Mountain
  16605. and C Worthy stuff doesn't either.  I had to go through quite a few
  16606. gyrations to their source code to get my memory back.
  16607. Good luck
  16608. Ron
  16609. ---------------
  16610. ** Current thread: C COMMUNICATIONS
  16611.  
  16612. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AMN0645 Date: 06/18/90
  16613. From: THOMAS ZERUCHA                                        Time: 07:10 pm
  16614.   To: CRAIG SMITH (Rcvd)                                    (Read 69 times)
  16615. Subj: R: C COMMUNICATIONS
  16616.  
  16617. Again, I have to caution you that it is 1.0, and "needs a little work".
  16618. Most of the problems and deficiencies are being addressed, but you are
  16619. likely to recieve 1.00 and will have to find a way to upgrade.  Their
  16620. windows toolkit is very good (though text only and no mouse support).
  16621. If you plan to get something 100% you may want to check out something
  16622. else, but if you can handle recompiling some source you can patch all the
  16623. holes yourself.
  16624. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  16625.  
  16626. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3ACR3448 Date: 06/08/90
  16627. From: GREGORY WILSON                                        Time: 10:57 pm
  16628.   To: GRANT ELLSWORTH (Rcvd)                                (Read 76 times)
  16629. Subj: R: MIX POWER C VS MSC
  16630.  
  16631. Thanks. I guess for $19.95, I almost have to get it. A friend of mine said
  16632. that I should also get the debugger (also $19.95). It is suppose to be
  16633. superior to Codeview. I do like the debugger in the new QuickC 2.5 however
  16634. and will probably stick to that and MSC.
  16635. Anyway,
  16636. Thanks!!!
  16637. Gregory Wilson
  16638. ---------------
  16639. Following thread
  16640.  
  16641. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3ADK0471 Date: 06/09/90
  16642. From: GRANT ELLSWORTH (Leader)                              Time: 04:07 pm
  16643.   To: GREGORY WILSON (Rcvd)                                 (Read 79 times)
  16644. Subj: R: MIX POWER C VS MSC
  16645.  
  16646. Gregory, I purchased both the compiler and the debugger to evaluate it as
  16647. a learning tool.  I was impressed.  It's well worth the $50 expense for
  16648. that purpose.  The POWERTRACE debugger and QC2.5's debugger may be equiv-
  16649. alent for your purposes.  The latest Borland TD2.0 release is supposedly
  16650. much better than the latest CodeView debugger and is CV/M$C compatible.
  16651. You might want to get it for use with your MSC programs.  Grant
  16652. ---------------
  16653. ** Current thread: MIX POWER C VS MSC
  16654.  
  16655. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3ADN2202 Date: 06/09/90
  16656. From: GREGORY WILSON                                        Time: 07:36 pm
  16657.   To: GRANT ELLSWORTH (Rcvd)                                (Read 81 times)
  16658. Subj: R: MIX POWER C VS MSC
  16659.  
  16660. Thanks for the info! I guess I will be getting the compiler since
  16661. the price is so nice. I like trying new things so another toy won't
  16662. hurt too bad at that price. I did not know about the new TD.
  16663. Thanks again,
  16664. Gregory Wilson
  16665.  
  16666. ---------------
  16667. ** Current thread: MIX POWER C VS MSC
  16668.  
  16669. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AHE1984 Date: 06/13/90
  16670. From: THOMAS ZERUCHA                                        Time: 10:33 am
  16671.   To: GREGORY WILSON (Rcvd)                                 (Read 72 times)
  16672. Subj: R: MIX POWER C VS MSC
  16673.  
  16674. Be sure to get the debugger.  I use Power C for all my small programs (I
  16675. may recompile them later).  The debugger doesn't have a lot of bells and
  16676. whistles, but makes the operation of the program very clear, especially
  16677. since you can watch your variables change (this can be done in other
  16678. debuggers, but you need to set up a window to see them, then specify each
  16679. one - and most don't provide a list, so you have to remember the exact
  16680. name).  PowerCTrace has everything like a menu.
  16681.    I haven't found many bugs (as of 1.3 - there was a problem with leap
  16682. years we found in 1988, and be careful when comparing far pointers).  I
  16683. have produced production code with it, and for the price it is a steal.
  16684. ---------------
  16685. ** Current thread: MIX POWER C VS MSC
  16686.  
  16687. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AHI1873 Date: 06/13/90
  16688. From: GREGORY WILSON                                        Time: 02:31 pm
  16689.   To: THOMAS ZERUCHA (Rcvd)                                 (Read 72 times)
  16690. Subj: R: MIX POWER C VS MSC
  16691.  
  16692. I just ordered POWERC with the Debugger. FOr the price, I have to try it!
  16693. Thanks again!
  16694. Gregory Wilson
  16695. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  16696.  
  16697. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AD11473 Date: 06/09/90
  16698. From: ROBERT BALSOVER                                       Time: 12:24 am
  16699.   To: STEVEN KEY (Rcvd)                                     (Read 75 times)
  16700. Subj: R: IDEAS PLEASE
  16701.  
  16702. Steven,
  16703. You're probably correct.  I thought it was 128 for the bios buffer, but
  16704. why don't you try it. (it couldn't hurt)
  16705. Bob
  16706. ---------------
  16707. Following thread
  16708.  
  16709. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AD11636 Date: 06/09/90
  16710. From: ROBERT BALSOVER                                       Time: 12:27 am
  16711.   To: DAVID ABBOTT (Rcvd)                                   (Read 76 times)
  16712. Subj: R: IDEAS PLEASE
  16713.  
  16714. David,
  16715. I haven't needed something like that before, so I can't help you.  It
  16716. might not hurt to try it anyway.
  16717. Bob
  16718. ---------------
  16719. ** Current thread: IDEAS PLEASE
  16720.  
  16721. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AD11751 Date: 06/09/90
  16722. From: ROBERT BALSOVER                                       Time: 12:29 am
  16723.   To: DAVID ABBOTT (Rcvd)                                   (Read 77 times)
  16724. Subj: R: IDEAS PLEASE
  16725.  
  16726. David,
  16727. It occurred to mee that it might be the limitation of the C library,
  16728. ungetch() might not stuff the keyboard buffer, just the buffer in the C
  16729. library.  Try to go direct to the buffer itself.
  16730. Bob
  16731. ---------------
  16732. ** Current thread: IDEAS PLEASE
  16733.  
  16734. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AEP2142 Date: 06/10/90
  16735. From: JIM MONROE                                            Time: 08:35 pm
  16736.   To: ROBERT BALSOVER (Rcvd)                                (Read 79 times)
  16737. Subj: R: IDEAS PLEASE
  16738.  
  16739. I think by looking at the Assb code for the functions, it will be possible
  16740. to decipher the problem.  I have not done that particular task yet but the
  16741. assb code usually halps me clear up the uniquie problems that I getOp hung
  16742. up on.
  16743. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  16744.  
  16745. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AD11536 Date: 06/09/90
  16746. From: ROBERT BALSOVER                                       Time: 12:25 am
  16747.   To: STEVEN KEY (Rcvd)                                     (Read 78 times)
  16748. Subj: R: MOVING TO TURBO C++
  16749.  
  16750. yep, $159 (+S&H) gets the works.
  16751. ---------------
  16752. Following thread
  16753.  
  16754. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AD12317 Date: 06/09/90
  16755. From: ROBERT BALSOVER                                       Time: 12:38 am
  16756.   To: GRANT ELLSWORTH (Rcvd)                                (Read 82 times)
  16757. Subj: R: MOVING TO TURBO C++
  16758.  
  16759. Grant,
  16760. You are right, this is a senseless debate.  A person should do as he
  16761. feels.
  16762. Happy trails
  16763. Bob
  16764. ---------------
  16765. ** Current thread: MOVING TO TURBO C++
  16766.  
  16767. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3ADE0479 Date: 06/09/90
  16768. From: GRANT ELLSWORTH (Leader)                              Time: 10:08 am
  16769.   To: ROBERT BALSOVER (Rcvd)                                (Read 79 times)
  16770. Subj: R: MOVING TO TURBO C++
  16771.  
  16772. Bob, Happy trails to you, too.  Grant
  16773. ---------------
  16774. ** Current thread: MOVING TO TURBO C++
  16775.  
  16776. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AEP2527 Date: 06/10/90
  16777. From: JIM MONROE                                            Time: 08:42 pm
  16778.   To: ROBERT BALSOVER (Rcvd)                                (Read 82 times)
  16779. Subj: R: MOVING TO TURBO C++
  16780.  
  16781. It seems that all of the arguing over price tag of the upgrade movement to
  16782. c++ or which ever route is available places price over function. If a
  16783. person needs or wants the item, go for it and not for the price tag. I
  16784. haver found that going directly to the source has produced my best results
  16785. over time. I am sure I could have saved a few hundred dollars through
  16786. shopping but I am not sure that it would have been worth the frustration.
  16787. While this is only my opinion, I would hope that we will see info on the
  16788. product and product application problems and solutions on the forum soon.
  16789. ---------------
  16790. ** Current thread: MOVING TO TURBO C++
  16791.  
  16792. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AFE1527 Date: 06/11/90
  16793. From: ROBERT BALSOVER                                       Time: 10:25 am
  16794.   To: JIM MONROE (Rcvd)                                     (Read 84 times)
  16795. Subj: R: MOVING TO TURBO C++
  16796.  
  16797. Jim,
  16798.      I have the compiler now and its worked fine so far.  I was
  16799. disapointed that td286 required 640k of extended memory to function, the
  16800. first press release on TD and Tools stated it only required 384k of
  16801. extended memory to function, which is what I have.  Turbo Profiles is
  16802. GREAT!  The new IDE is nice, but takes a little tim to get used to because
  16803. there are some differences between keystokes in it and the old IDE.
  16804.      Jim, actually Grant and I were not arguing about price, it was the
  16805. principle of what Borland was doing.  They pulled a very MS kind of stunt
  16806. and are getting a lot of heat from users in the forem on CIS.  The said it
  16807. was *not* a upgrade but a special offer, then they leave out the manuals,
  16808. they also dumped all availible product on retail stores and made the
  16809. *loyal* user cool his heels.  No Jim, price was not the issue.  If they
  16810. offered the same price or even $20 more for the TC++ Prof package,
  16811. including all manuals and didn't make the *loyal* user wait while the guy
  16812. on the street picked it up and Software ETC., I think there would have
  16813. been no problem.
  16814. Bob
  16815. ---------------
  16816. ** Current thread: MOVING TO TURBO C++
  16817.  
  16818. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AFN0596 Date: 06/11/90
  16819. From: JIM MONROE                                            Time: 07:09 pm
  16820.   To: ROBERT BALSOVER (Rcvd)                                (Read 83 times)
  16821. Subj: R: MOVING TO TURBO C++
  16822.  
  16823. It seems that all ro at least most of the software houses have gotten to
  16824. the point of ignoring the customer.  This seems like the attitude of the
  16825. Big computer manufacture of old. What is good for xxx is good for you the
  16826. customer, you (the customer are just to dumb to understand) just need
  16827. additional training.
  16828. Will you be able to make the Users Group this week?
  16829. ---------------
  16830. ** Current thread: MOVING TO TURBO C++
  16831.  
  16832. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AFN1922 Date: 06/11/90
  16833. From: ROBERT BALSOVER                                       Time: 07:32 pm
  16834.   To: JIM MONROE (Rcvd)                                     (Read 81 times)
  16835. Subj: R: MOVING TO TURBO C++
  16836.  
  16837. Jim,
  16838. When and where will the meeting be?
  16839. Bob
  16840. ---------------
  16841. ** Current thread: MOVING TO TURBO C++
  16842.  
  16843. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AGP2415 Date: 06/12/90
  16844. From: GRANT ELLSWORTH (Leader)                              Time: 08:40 pm
  16845.   To: ROBERT BALSOVER (Rcvd)                                (Read 78 times)
  16846. Subj: R: MOVING TO TURBO C++
  16847.  
  16848. Bob, re: td286(? -> not td386?) and 640K extended memory ...
  16849. That's the 1st i've heard about that.  Could you be doing something awry
  16850. in your setup or configuration stuff such that your triggering more
  16851. memory use than absolutely necessary?  Grant
  16852. ---------------
  16853. ** Current thread: MOVING TO TURBO C++
  16854.  
  16855. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AIS2905 Date: 06/14/90
  16856. From: ROBERT BALSOVER                                       Time: 11:48 pm
  16857.   To: GRANT ELLSWORTH (Rcvd)                                (Read 76 times)
  16858. Subj: R: MOVING TO TURBO C++
  16859.  
  16860. Grant,
  16861.      It reports that when I try to run it, then it aborts.  I don't even
  16862. get into the opening screen of TD286.  I believe it also says 640k
  16863. extended memory is required in the manuals.
  16864. Bob
  16865. ---------------
  16866. ** Current thread: MOVING TO TURBO C++
  16867.  
  16868. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AJR2180 Date: 06/15/90
  16869. From: GRANT ELLSWORTH (Leader)                              Time: 10:36 pm
  16870.   To: ROBERT BALSOVER (Rcvd)                                (Read 72 times)
  16871. Subj: R: MOVING TO TURBO C++
  16872.  
  16873. 640K EXTENDED memory???!!!!???  That's an unusual amount of EXTENDED
  16874. memory for a DOS-based program  to be asking for.  Are you SURE it said
  16875. EXTENDED, not EXPANDED??   What if you had an EMS driver, or a 386 + much
  16876. extra extended memory + qemm (or similar ems driver)???    What you report
  16877. is a little baffling.  Grant
  16878. ---------------
  16879. ** Current thread: MOVING TO TURBO C++
  16880.  
  16881. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AK12584 Date: 06/16/90
  16882. From: ROBERT BALSOVER                                       Time: 01:43 am
  16883.   To: GRANT ELLSWORTH (Rcvd)                                (Read 75 times)
  16884. Subj: R: MOVING TO TURBO C++
  16885.  
  16886. Grant,
  16887.      I always get extended and expanded mixed up, let me state another
  16888. way.  The memory above 1 meg that needs the processor to run in protected
  16889. mode.  Part of the problem maybe that Borland is using the TurboDrive(TM)
  16890. to operate in protected mode, it may not be common knowledge but they
  16891. licenced Eclipse's 286 Dos extender for their TurboDrive.  Eclipse does
  16892. not support virtual memory for data segements like their 386 extender
  16893. does, the removed it due to problems they were having.  I found this out
  16894. when I called Eclipse about the add in the Programmers Connection,
  16895. Programmers Connection is selling a special TC only version if their 286
  16896. extender cheap.  Anyway, TD286 may need the memory for its own data.
  16897. Thats my best guess.
  16898. Bob
  16899. ---------------
  16900. ** Current thread: MOVING TO TURBO C++
  16901.  
  16902. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AMP0540 Date: 06/18/90
  16903. From: JIM MONROE                                            Time: 08:09 pm
  16904.   To: ROBERT BALSOVER (Rcvd)                                (Read 75 times)
  16905. Subj: R: MOVING TO TURBO C++
  16906.  
  16907. I am sorry that I did not get back to you on time, the meetings are held
  16908. the 2nd thursday and the 4th tuesday. They start at 7:00 P.M. and are held
  16909. at the old Allis Chalmers club house. It is now a resturant and I beleive
  16910. that it is called Sue and Shar's Southern Plantation.  The Tuesday meeting
  16911. will be a swap fest ( I think).  Try to come out and see if you are
  16912. interested in the group.
  16913. s
  16914. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  16915.  
  16916. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AD11872 Date: 06/09/90
  16917. From: ROBERT BALSOVER                                       Time: 12:31 am
  16918.   To: GREGORY WILSON (Rcvd)                                 (Read 76 times)
  16919. Subj: R: POINTERS TO STRINGS
  16920.  
  16921. Gregory,
  16922. Using calloc() would be safer, you'd know for a fact that the string was
  16923. null terminated.
  16924. Bob
  16925. ---------------
  16926.  
  16927. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3ADK0811 Date: 06/09/90
  16928. From: GRANT ELLSWORTH (Leader)                              Time: 04:13 pm
  16929.   To: ROBERT BALSOVER (Rcvd)                                (Read 77 times)
  16930. Subj: SW UPGRADE SCAMS ...
  16931.  
  16932. Bob, I revisited our little discussion of whether to "upgrade" to TC++
  16933. via mail-order "new" order or via BI "special to registered users".  I
  16934. also browsed the uproar on CI$ over the TASM 2.0 manuals issue --- an
  16935. uproar I was unaware of when I wrote my "quibbling at the margin" mes-
  16936. sage.  After some reflection, I'll call the spring-summer programming
  16937. language upgrade scene a shoddy scandal.  Borland, Micro-slop, and
  16938. Watcom (Waterloo) (and maybe others) are each engaging in a "screw the
  16939. registered user" game.  To wit:
  16940.  
  16941. 1.  M$ recalls M$C 6.0 from beta only to release it a short time later
  16942.     no less, and probably even more bug-infested, than release 5.1
  16943.  
  16944.     M$ touted the 6.0 release as their best effort at releasing at
  16945.     a relatively bug-free language product where most really awful
  16946.     known buggers from 5.1 were addressed
  16947.  
  16948.     As I gather from some threads on CI$, M$ was really deceiving the
  16949.     user base, or fooling themselves.  Anyway, a great number of devel-
  16950.     opers have been suckered into the upgrade to get some insect relief,
  16951.     if not access to "more advanced" features
  16952.  
  16953.     Although we have an "uninstalled", but registered, M$C5.1, we got
  16954.     notice in the mail on the upgrade availability well AFTER the public
  16955.     announcement --- well, at least we got an "upgrade at reduced prices"
  16956.     notice ... product quality notwithstanding ....
  16957.  
  16958. 2.  Watcom announced its super-duper WATCOMC 8.0 which competes with M$
  16959.     in the OS/2, 386 protected mode code, etc ..
  16960.  
  16961.     Yet, I have yet to see an "upgrade offer" or similar advertisement
  16962.     from Watcom --- I did upgrade to WC7.0 when it was 1st announced via
  16963.     an upgrade offer from Watcom
  16964.  
  16965.     Seems like the Waterloo group is expecting the users to start again
  16966.     with a clean slate.  No upgrades.  List/Mail-order prices only.
  16967.  
  16968. 3.  Borland pulls a "bait and switch" on its "New Product" special offer
  16969.     to TC2.0 users
  16970.  
  16971.     BI says: It's a new product.  Special intro prices to current TC2.0
  16972.     user base.
  16973.  
  16974.     And your ProPak is handled as an upgrade ... no full manuals for your
  16975.     TASM ...  (and BI didn't tell you)
  16976.  
  16977.     BI also did not provide the registered user base with any lead time
  16978.     to get the product(s) ahead of the mail-order rush, etc..  So, you
  16979.     can get the full boat from the mail-order folks now (and get the full
  16980.     manual set), or you can wait 1 month for your "new product"
  16981. (upgrade?!)
  16982.     ... with an almost marginal price differential
  16983.  
  16984. I won't go into the gory details, but it reads like the new rage,
  16985. M$WINDOWS
  16986. 3.0 won't work with a lot of the non-IBM and non-MS software/hardware out
  16987. there right now.  Anyway, it's supposed to be a multi-tasker (on a 386,at
  16988. least), and I read it can't even keep up with DV.  Meanwhile, the
  16989. reviewers
  16990. seem to be ignoring DV entirely --- they're seduced by the graphical user-
  16991. confuser and wild rodents.  DV DOES support rodents, provides slightly
  16992. better
  16993. task-to-task cut-and-paste capabilities ,,, yet the reviewers ... treat M$
  16994. as
  16995. an unasailable diety ....
  16996.  
  16997. Quarterdeck is also guilty as sin ... : announces QEMM5.0, DV2.26, etc,
  16998. and
  16999. mails out an upgrade notice to users which is practically expired by the
  17000. time
  17001. it arrives.  QOS may have a better underlying product, but QOD sure
  17002. doesn't
  17003. support it, document it (the API anyway) accurately --- leaving those who
  17004. would extend its (DV) applicability to spin wheels for days, weeks,
  17005. months,
  17006. etc., trying to figure out what QOS REALLY meant by what was not written
  17007. in
  17008. the documentation.
  17009.  
  17010. This whole situation is scandalous.   It reminds me of IBM's consistently
  17011. "questionable" behavior in its handling of the 370 mainframe products ---
  17012. both H/W and S/W --- while the suckers (customer base)t on pouring
  17013. good money and time after bad.  DEC had opportunities, but continued con-
  17014. templating its naval. ...
  17015.  
  17016. While I would hope ALL the vendors would get their act together and start
  17017. (resume(?)) delivering quality products, giving registered users an advan-
  17018. tage in registering, and carefully docuemt what is delivered, I think this
  17019. behavior will be curtailed only by successful non-North-American competi-
  17020. tion, like from the Soviet Union (horrors of horrors) and Eastern Europe,
  17021. which are just beginning to emerge from the darkness, full of energy, and
  17022. looking for opportunities!  I recently read an article which delineated
  17023. how the software authors in these countries are doing a heck of a lot more
  17024. with so much less ...
  17025.  
  17026. Grant
  17027. ---------------
  17028. Following thread
  17029.  
  17030. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3ADN1056 Date: 06/09/90
  17031. From: ROBERT BALSOVER                                       Time: 07:17 pm
  17032.   To: GRANT ELLSWORTH (Rcvd)                                (Read 74 times)
  17033. Subj: R: SW UPGRADE SCAMS ...
  17034.  
  17035. Grant,
  17036.      After looking over c0.asm in the startup directory for TC++, I'm
  17037. convinced that they had originally planed this to be TC 3.0.  It says TC
  17038. 3.0 in c0.asm!  Well anyway, thats water under the bridge now.
  17039.      I hold a unfavorable opinion as to the Computer magizine industry.
  17040. Even DDJ show signs of the problems you mentioned in your message.  That
  17041. last magizine I *really* liked was Micro Cornucopia, and their final issue
  17042. was last month.
  17043. Bob
  17044. ---------------
  17045. ** Current thread: SW UPGRADE SCAMS ...
  17046.  
  17047. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AEG3097 Date: 06/10/90
  17048. From: GRANT ELLSWORTH (Leader)                              Time: 12:51 pm
  17049.   To: ROBERT BALSOVER (Rcvd)                                (Read 79 times)
  17050. Subj: R: SW UPGRADE SCAMS ...
  17051.  
  17052. I liked Micro-Cornucopia, too.  Seems like the real good mags don't last
  17053. long.  Grant
  17054. ---------------
  17055. ** Current thread: SW UPGRADE SCAMS ...
  17056.  
  17057. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AHE1149 Date: 06/13/90
  17058. From: THOMAS ZERUCHA                                        Time: 10:19 am
  17059.   To: GRANT ELLSWORTH (Rcvd)                                (Read 70 times)
  17060. Subj: R: SW UPGRADE SCAMS ...
  17061.  
  17062. Watcom 8.0 is available on an upgrade basis (as is Power C 2.0).  The
  17063. details should be in the file I uploaded to the Mahoney collection.
  17064. Not all software houses have a computer that can print thousands of
  17065. letters.  I would suggest contacting Watcom directly for upgrade
  17066. information (part of this may be that it is not officially released yet,
  17067. though that may occur any day, another part may be that there are two
  17068. versions to upgrade to - standard and pro).
  17069.   In general I do agree about upgrades - they shouldn't be a means of
  17070. profit, but at the same time I don't offer a free lifetime guarantee on
  17071. software I write.  Any MIX (Power C) product can be upgraded for $5/disk,
  17072. so not everyone is trying to rip people off.
  17073. ---------------
  17074. ** Current thread: SW UPGRADE SCAMS ...
  17075.  
  17076. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AHF0260 Date: 06/13/90
  17077. From: GRANT ELLSWORTH (Leader)                              Time: 11:04 am
  17078.   To: THOMAS ZERUCHA (Rcvd)                                 (Read 68 times)
  17079. Subj: R: SW UPGRADE SCAMS ...
  17080.  
  17081. I don't agree... I don't see why s/w upgrades for registered users should
  17082. NOT be profitable.   But, I sure don't understand why they need to be
  17083. deceptive or disguised.
  17084.  
  17085. It's the deception ripofrf.
  17086. ---------------
  17087. ** Current thread: SW UPGRADE SCAMS ...
  17088.  
  17089. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AIN2225 Date: 06/14/90
  17090. From: GRANT ELLSWORTH (Leader)                              Time: 07:37 pm
  17091.   To: THOMAS ZERUCHA (Rcvd)                                 (Read 69 times)
  17092. Subj: R: SW UPGRADE SCAMS ...
  17093.  
  17094. I called Watcom directly on their 800 number.  They are offering a
  17095. generous upgrade price to owners of WC products.  If you own and have
  17096. registered WC7.0(286), the upgrade to WC8.0(286) Standard Edition is
  17097. $125, upgrade to the Professional Edition(286) is $225.  No upgrade
  17098. prices are offered for upgrading from WC7.0(286) to WC8.0(386)-any
  17099. "edition".  Current owners of WC7.0(386) may upgrade to WC8.0(386) for
  17100. about $400 (against 1200 list, and 940, best street price I could find).
  17101. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  17102.  
  17103. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3ADM3406 Date: 06/09/90
  17104. From: ROBERT WARREN                                         Time: 06:56 pm
  17105.   To: ALL                                                   (Read 74 times)
  17106. Subj: ATOF ABNORMAL TERMINATION. SCANF. TURBO C
  17107.  
  17108. Maybe someone can help me figure out why I'm getting an abnormal
  17109. termination.
  17110. I'm using Borland Turbo C  2.0   and am just learning to use C.
  17111. ------------------------------------*
  17112. Following program:
  17113. #include <stdio.h>
  17114. #include <stdlib.h>
  17115. #include <math.h>
  17116. main()
  17117. {
  17118.    double  x = 0.0;
  17119.    x = atof("33.3");
  17120.    printf("\n Converted to: %f",x);
  17121. }
  17122. ==================================================*
  17123. I get no warnings or messages when I compile in the integrated
  17124. environement.   However when I run this program,  caused on the
  17125. atof function  the program aborts with the following message:
  17126.  scanf : floating point formats not linked
  17127. Abnormal program termination
  17128. ====================================================*
  17129. I think it has to be something in my installation.
  17130. The atof seems to work just fine - when I run this program
  17131. on another machine.
  17132. Any ideas?
  17133. ---------------
  17134. Following thread
  17135.  
  17136. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3ADN1411 Date: 06/09/90
  17137. From: ROBERT BALSOVER                                       Time: 07:23 pm
  17138.   To: ROBERT WARREN (Rcvd)                                  (Read 76 times)
  17139. Subj: R: ATOF ABNORMAL TERMINATION. SCANF. TURBO C
  17140.  
  17141. Robert,
  17142.      Thats the result of a known bug in TC 2.0 (or 2.1).  The compiler
  17143. fails to make reference to a label in the MATH?.LIB.  This is usually only
  17144. a problem in small test programs like the one you posted.  I think the
  17145. compiler will generate the proper code if you reference a pointer of the
  17146. double type:
  17147. .
  17148. double *bug_fix;
  17149. double x = 0.0;
  17150. .
  17151.      *bug_fix = x     /* this will cause the proper code to generate */
  17152. ...
  17153. I hope the fixes it for you.
  17154. Bob
  17155. ---------------
  17156. ** Current thread: ATOF ABNORMAL TERMINATION. SCANF. TURBO C
  17157.  
  17158. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AEN0494 Date: 06/10/90
  17159. From: ROBERT WARREN                                         Time: 07:08 pm
  17160.   To: ROBERT BALSOVER (Rcvd)                                (Read 77 times)
  17161. Subj: R: ATOF ABNORMAL TERMINATION. SCANF. TURBO C
  17162.  
  17163. Thanks Robert B.  That enabled me to proceed.
  17164. --------------------------------------------------*
  17165. I think I've got a Borland Turbo C 2.01
  17166. My TC.EXE file is dated 5-11-89, and is 290525 bytes.
  17167. Any idea if I can get a newer version.
  17168. ---------------
  17169. ** Current thread: ATOF ABNORMAL TERMINATION. SCANF. TURBO C
  17170.  
  17171. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AFE0805 Date: 06/11/90
  17172. From: ROBERT BALSOVER                                       Time: 10:13 am
  17173.   To: ROBERT WARREN (Rcvd)                                  (Read 80 times)
  17174. Subj: R: ATOF ABNORMAL TERMINATION. SCANF. TURBO C
  17175.  
  17176. Robert,
  17177. TC 2.01 is the latest version of 'TC', TC++ is now available at most
  17178. retail stores and Borland is offering a TC++ only upgrade price of about
  17179. $79 but it takes awhile for them to ship and discount retail stores and
  17180. mail order houses have it for about the same price.  I think that TC 2.01
  17181. will work fine in larger programs, its just very small programs like yours
  17182. that causes the bug to surface.
  17183. Bob
  17184. ---------------
  17185. ** Current thread: ATOF ABNORMAL TERMINATION. SCANF. TURBO C
  17186.  
  17187. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AFN0802 Date: 06/11/90
  17188. From: JIM MONROE                                            Time: 07:13 pm
  17189.   To: ROBERT BALSOVER (Rcvd)                                (Read 80 times)
  17190. Subj: R: ATOF ABNORMAL TERMINATION. SCANF. TURBO C
  17191.  
  17192. I tried the code in you original message and compiled it using the MIX
  17193. compiler is all memorary models. It worked with out any adverse effect.
  17194. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  17195.  
  17196. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3ADP1358 Date: 06/09/90
  17197. From: KEVIN KNORR                                           Time: 08:22 pm
  17198.   To: ALL                                                   (Read 74 times)
  17199. Subj: HELP!
  17200.  
  17201. I am trying to compile a C program and in the linking phase I get the
  17202. message
  17203. undefined symbol ulmul%% first referenced in etc...
  17204. I searched all of the program including the "includes" and I can not
  17205. find "ulmul%%" or "ulmul%%()" or anything close to it.
  17206. I ran lint on the program and still no luck.
  17207. any ideas.
  17208. I am trying to compile this on an NCR tower running UNIX V 3.01.00
  17209. ---------------
  17210. Following thread
  17211.  
  17212. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AIP0469 Date: 06/14/90
  17213. From: JEFF NOWLAND                                          Time: 08:07 pm
  17214.   To: KEVIN KNORR (Rcvd)                                    (Read 72 times)
  17215. Subj: R: HELP!
  17216.  
  17217. Kevin,
  17218. ulmul%% looks like a compiler used routine for multiplying unsigned long
  17219. integers. You wouldn't find it in your code because its in one of the
  17220. runtime libraries.  Its probably called by the compiler everytime you code
  17221. something like:
  17222. unsigned long x=1L;;
  17223.   x *= 2;
  17224. JDNowland.
  17225. ---------------
  17226. ** Current thread: HELP!
  17227.  
  17228. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AEN0755 Date: 06/10/90
  17229. From: JOHN HEY                                              Time: 07:12 pm
  17230.   To: GRANT ELLSWORTH (Rcvd)                                (Read 76 times)
  17231. Subj: DESQVIEW API
  17232.  
  17233. Grant,
  17234.  
  17235. You recently made a statement (in the context of a long discourse
  17236. regarding the lousy support policies of various big-name companies) about
  17237. the DESQview API documentation, which indicated that the doc's weren't
  17238. really very well written, etc.
  17239.  
  17240. This concerns me, since for some time now I've considered switching to the
  17241. DESQview API for a C project my company is working on.  If you could, I'd
  17242. appreciate a few more comments about the API's deficiencies, so that I can
  17243. take those into account in making my decision.
  17244.  
  17245. Thanks!
  17246. John Hey--
  17247. ---------------
  17248. Following thread
  17249.  
  17250. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AFN1410 Date: 06/11/90
  17251. From: GRANT ELLSWORTH (Leader)                              Time: 07:23 pm
  17252.   To: JOHN HEY (Rcvd)                                       (Read 76 times)
  17253. Subj: R: DESQVIEW API
  17254.  
  17255. John, The DV C-Lib API for DV2.25 is really pretty good.  I have yet to
  17256. stumble into any bugs.  It also does what the specs/programmer's guide
  17257. says AT A MACRO LEVEL (that is, you can make it do what the specs say,
  17258. but sometimes after extensive gyrations).  What is often unclear or
  17259. totally absent is clear explanation of what the order (sequence) of the
  17260. API calls really has to be in order to get the effect you want.  Also,
  17261. there are sometimes a lack of #define statements for specific operations
  17262. which you expect to be there --- e.g. to position one window with respect
  17263. to another you must specify a vertical relationship ... the C api is not
  17264. clear on the value to use and provides no #define for the operation, while
  17265. it does provide the necessary details for horizontal positioning.   I had
  17266. to ferret out an answer by guessing from some info implied in the general
  17267. ASM-oriented API Guide.   It seemed to me that I spent days at a time
  17268. figuring out what was meant by what the C-Interface spec said and how it
  17269. related to the commentary in the API Guide.
  17270.  
  17271. With respect to technical support, I found the forum on CI$ a hopeless
  17272. exercise unless another user who had the same mis-step read my msgs.  I
  17273. also gather that phone support --- even for those with "priority service"
  17274. leaves something to be desired.
  17275.  
  17276. All this notwithstanding, once I "hacked" away at this thing and made
  17277. extensive notes on what the specs didn't really specify, I found the
  17278. API powerful and usable.  I just think that any project based on using
  17279. the DV API needs to allocate a fair bit of time (1 person-month per
  17280. programmer) to figure the more subtle things out.  And I believe that
  17281. learning to use it requires some pretty darned sophisticated debugging
  17282. skills.  It's not a system for  beginners or amateurs.  Grant
  17283.  
  17284. ps:  Please understand what I meant by "bug" above ... a bug is when the
  17285. software does not behave as specified when used explicitly as specified.
  17286. It's the recurring lack of the necessary specificity in the documentation
  17287. which "bugs" me --- but, it's a little far fetched to call this deficien-
  17288. cy a bug.
  17289.  
  17290. If you do decide to use the C-API, I recommend that you employ the
  17291. practice of "build a little, test a little", and test each and every one
  17292. of your assumptions about what you think the dox meant thoroughly!!
  17293. ---------------
  17294. ** Current thread: DESQVIEW API
  17295.  
  17296. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AGL2723 Date: 06/12/90
  17297. From: JOHN HEY                                              Time: 05:45 pm
  17298.   To: GRANT ELLSWORTH (Rcvd)                                (Read 73 times)
  17299. Subj: R: DESQVIEW API
  17300.  
  17301. I appreciate your extensive comments on the DesqView API ... Thanks a
  17302. whole lot!
  17303.  
  17304. John Hey--
  17305. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  17306.  
  17307. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AFK1743 Date: 06/11/90
  17308. From: DAVID ABBOTT                                          Time: 04:29 pm
  17309.   To: ALL                                                   (Read 76 times)
  17310. Subj: KEYBOARD BUFFER
  17311.  
  17312. Where is it, and how can i stuff it.  I'm trying to find a function that
  17313. will un-get-a-string.  ungetch() puts one character back into the keyboard
  17314. buffer, but I want to put back a string (less than 12 characters);  Ive
  17315. tried repeated calls to ungetch (), ungetting the string backwards...but
  17316. the doc for ungetch states you can only call it once in-between calls to
  17317. getch()... Can anybody help me on this...  I would be willing to share
  17318. some nifty date management routines???
  17319.  
  17320.   Thanks, David Abbott
  17321. ---------------
  17322. Following thread
  17323.  
  17324. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AFP1884 Date: 06/11/90
  17325. From: PHIL HILL                                             Time: 08:31 pm
  17326.   To: DAVID ABBOTT (Rcvd)                                   (Read 80 times)
  17327. Subj: R: KEYBOARD BUFFER
  17328.  
  17329. David,
  17330.  
  17331. The following works in Turbo C.  Other compilers may have different
  17332. implementations for disable()/enable().  The indirection doesn't
  17333. do much for readability, I guess - but it does get the job done.
  17334.  
  17335. #include <dos.h>     /* for disable()/enable() */
  17336. stuff_kb(unsigned char *string){
  17337.  
  17338. int  i;
  17339. char far *buff_head = (char far *)0x40001A,
  17340.      far *buff_tail = (char far *)0x40001C;
  17341.  
  17342. *buff_head = *buff_tail = 0x1E;
  17343. for (i = 1; (i <= 15 && *string); i++){
  17344.     disable();
  17345.     *(buff_tail + (i << 1)) = *string++;
  17346.     *buff_tail += 2;
  17347.     enable();
  17348. }/* end for */
  17349. }/* eof stuff_kb() */
  17350.  
  17351. ---------------
  17352. ** Current thread: KEYBOARD BUFFER
  17353.  
  17354. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AGD2328 Date: 06/12/90
  17355. From: DAVID ABBOTT                                          Time: 09:38 am
  17356.   To: PHIL HILL (Rcvd)                                      (Read 73 times)
  17357. Subj: R: KEYBOARD BUFFER
  17358.  
  17359. Phil,
  17360.   Thanks alot, I'll try this right away...I knew there had to someone who
  17361. knew where this guy was.  Again thanks..If I can ever be of any help, just
  17362. ask.
  17363.  
  17364. David Abbott
  17365. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  17366.  
  17367. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AFN2200 Date: 06/11/90
  17368. From: ROBERT BALSOVER                                       Time: 07:36 pm
  17369.   To: JIM MONROE (Rcvd)                                     (Read 78 times)
  17370. Subj: R: TURBOC COMM CODE
  17371.  
  17372. Jim
  17373. Be careful with the source from that book,  it has a lot of errors
  17374. reported using TC in the large memory model.  I don't think he tested the
  17375. source in anything other than the small model.
  17376. Bob
  17377. ---------------
  17378. Following thread
  17379.  
  17380. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AKR2950 Date: 06/16/90
  17381. From: OTTO PORTER                                           Time: 10:49 pm
  17382.   To: JIM MONROE (Rcvd)                                     (Read 73 times)
  17383. Subj: R: TURBOC COMM CODE
  17384.  
  17385. Thanks for the suggestion.  I remember reading a review of this book
  17386. sometime ago and thought that it would be worthwhile.
  17387.  
  17388. Otto
  17389. ---------------
  17390. ** Current thread: TURBOC COMM CODE
  17391.  
  17392. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AMP0677 Date: 06/18/90
  17393. From: JIM MONROE                                            Time: 08:11 pm
  17394.   To: ROBERT BALSOVER (Rcvd)                                (Read 74 times)
  17395. Subj: R: TURBOC COMM CODE
  17396.  
  17397. I have not entered that much of it, I am using the MIX compiler and note
  17398. that a number of changes must be made. I wish that the books that are in
  17399. the market would be more carefully reviewed. I have the same problems with
  17400. text books. I teach accounting on a part time basis and find it quite
  17401. frustrating when the text has an error in a problem that I am attempting
  17402. to demonstrate.
  17403. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  17404.  
  17405. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AGP3180 Date: 06/12/90
  17406. From: GRANT ELLSWORTH (Leader)                              Time: 08:53 pm
  17407.   To: ALL                                                   (Read 71 times)
  17408. Subj: PRINT.COM(MSDOS3.3) UNCOOKED PLEASE
  17409.  
  17410. I know some of you are deep_water gurus ... so help the "front-man" ...
  17411. see my message on PRINT.COM in the MSDOS-Hot Topics, 3AGP2897 (refno).
  17412. Thanks for any help.  Grant
  17413. ---------------
  17414.  
  17415. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AHA2376 Date: 06/13/90
  17416. From: STEVE BOOTH                                           Time: 06:39 am
  17417.   To: ALL                                                   (Read 73 times)
  17418. Subj: DBASE ROUTINES
  17419.  
  17420. Hi Y'All,
  17421.    I'm looking for some good C routines which work with data
  17422. base files.  At this point, I'm just in the thinking stage,
  17423. it would be nice if something in the Shareware realm exists...
  17424. I'm not really looking to put out several hundred $$.  Have a
  17425. hard enuf time justifying what I do spend on the beastie.
  17426. I decided to spring for the TC++ upgrade and really can't afford
  17427. much at the present time. It would be great if there were something
  17428. on the order of the "CXL" librarys.  Anyone out there got any ideas??
  17429.  
  17430.    Regards, Steve...
  17431. ---------------
  17432. Following thread
  17433.  
  17434. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AHI2996 Date: 06/13/90
  17435. From: GREGORY WILSON                                        Time: 02:49 pm
  17436.   To: STEVE BOOTH (Rcvd)                                    (Read 74 times)
  17437. Subj: R: DBASE ROUTINES
  17438.  
  17439.  SB>    I'm looking for some good C routines which work with data
  17440.  SB> base files.  At this point, I'm just in the thinking stage,
  17441.  SB> it would be nice if something in the Shareware realm exists...
  17442.  SB> I'm not really looking to put out several hundred $$.  Have
  17443.  SB> a hard enuf time justifying what I do spend on the beastie.
  17444.  SB> I decided to spring for the TC++ upgrade and really can't
  17445.  SB> afford much at the present time. It would be great if there
  17446.  SB> were something on the order of the "CXL" librarys.  Anyone
  17447.  SB> out there got any ideas??
  17448.  
  17449. Steve,
  17450. This message sounds just like the one I was asking about a month ago!
  17451. After looking on hundreds of BBS's and talking to several people I have
  17452. come up with two libraries. One is the SOFT C library. There is a public
  17453. domain version available called SCD113.ZIP. I am not sure if it is here or
  17454. not. It is completely compatible with DBASE III/IV files and has many
  17455. command. The shareware version is a full working medium model lib.
  17456. Registration is $30 for the object code, $100 for the source. Another
  17457. option is the MIX DATABASE TOOLCHEST available from MIX software for
  17458. $19.95. It is really nice. This lib allows you to have variable length
  17459. fields/keys and has conversion programs to convert to and from DBASE
  17460. format. It comes with a good paperback book and a great demo. The address
  17461. and phone number can be found in many programming mags. If you cannot find
  17462. it, let me know and I will find the phone number for you (I am at work
  17463. now and do not have access to the number). The MIX TOOLCHEST does not
  17464. allow record locking therefore making 'shared database' applications a bit
  17465. complicated but the people at MIX tell me that the next version will
  17466. have the ability. Overall it is the closest thing I can find to the
  17467. quality of CXL (I swear by it) and even comes with support!
  17468. Hope this helps! If you come across any other options, please tell me
  17469. since I am still comparing and looking!
  17470. Talk to you later,
  17471. Gregory Wilson
  17472. SYSOP, The Ltd. BBS 708-213-1304 <==== Call sometime!!
  17473. ---------------
  17474. ** Current thread: DBASE ROUTINES
  17475.  
  17476. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AIC1324 Date: 06/14/90
  17477. From: STEVE BOOTH                                           Time: 08:22 am
  17478.   To: ALL                                                   (Read 71 times)
  17479. Subj: R: DBASE ROUTINES
  17480.  
  17481. Message CC'd to:
  17482.      GREGORY WILSON
  17483.      ALL
  17484.  
  17485. Hi,
  17486.  
  17487.      Does anyone have a C dbase library called SCD113.ZIP
  17488. available that they would be willing to upload?  Or tell me
  17489. where I could call to be able to download it?
  17490.  
  17491.      Thanks,
  17492.          Steve Booth...
  17493. ---------------
  17494. ** Current thread: DBASE ROUTINES
  17495.  
  17496. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AIF1208 Date: 06/14/90
  17497. From: GREGORY WILSON                                        Time: 11:20 am
  17498.   To: STEVE BOOTH (Rcvd)                                    (Read 73 times)
  17499. Subj: R: DBASE ROUTINES
  17500.  
  17501. Steve, I will upload it now. I saw that you dropped by my board. If you
  17502. will call back and complete Questionnaire #1, you will get a free week of
  17503. access so you can download my good 'C' stuff. Next time you get on, do the
  17504. questionnaire and then try paging me.
  17505. Talk to you later,
  17506. Gregory Wilson!
  17507. ---------------
  17508. ** Current thread: DBASE ROUTINES
  17509.  
  17510. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AMR2261 Date: 06/18/90
  17511. From: GREGORY WILSON                                        Time: 10:37 pm
  17512.   To: JIM MONROE (Rcvd)                                     (Read 68 times)
  17513. Subj: R: DBASE ROUTINES
  17514.  
  17515.  JM> I have acquired the c/database toolchest from MIX in Texas.
  17516.  JM> It is available with source and I think it was in the $50.00
  17517.  JM> range. I do not have a phone number but there address is
  17518.  
  17519. I received my MIX DB TOOLCHEST last week. It looks great! The only
  17520. complaint I have is that it does not support record locking but the people
  17521. at MIX software tell me that the next release should support it.
  17522. Thanks for your time!
  17523. Gregory Wilson
  17524. ---------------
  17525. ** Current thread: DBASE ROUTINES
  17526.  
  17527. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3ANS2884 Date: 06/19/90
  17528. From: JIM MONROE                                            Time: 11:48 pm
  17529.   To: GREGORY WILSON (Rcvd)                                 (Read 68 times)
  17530. Subj: R: DBASE ROUTINES
  17531.  
  17532. I beleive that the version I have only supports one memorary model. Since
  17533. then MIX has upgraded to support small medium and large models. Does you
  17534. version support all models?
  17535. ---------------
  17536. ** Current thread: DBASE ROUTINES
  17537.  
  17538. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3APE2808 Date: 06/20/90
  17539. From: GREGORY WILSON                                        Time: 10:46 am
  17540.   To: JIM MONROE (Rcvd)                                     (Read 69 times)
  17541. Subj: R: DBASE ROUTINES
  17542.  
  17543. It still only supports medium model. I immediately called to
  17544. complain and they told me that I needed to send $10 more for the
  17545. source so I could create any model lib I wanted. I wish they had
  17546. mentioned that in the ad. Anyway...I guess $10 wont hurt too much.
  17547. Gregory Wilson
  17548. ---------------
  17549. ** Current thread: DBASE ROUTINES
  17550.  
  17551. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AWQ0929 Date: 06/27/90
  17552. From: JIM MONROE                                            Time: 09:15 pm
  17553.   To: GREGORY WILSON (Rcvd)                                 (Read 61 times)
  17554. Subj: R: DBASE ROUTINES
  17555.  
  17556. I guess I will have to also send then the $10.00 even though I hate to get
  17557. nickled and dimed on these type of things
  17558. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  17559.  
  17560. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AHE1649 Date: 06/13/90
  17561. From: THOMAS ZERUCHA                                        Time: 10:27 am
  17562.   To: GREGORY WILSON (Rcvd)                                 (Read 73 times)
  17563. Subj: R: SIMPLE 'C' QUESTION
  17564.  
  17565. static when applied to something otherwise global makes it local to that
  17566. module (i.e. the portion of the program in the particular file).
  17567. So, in the first case (no static), a,b, and c would be visible from
  17568. another module that externed them.  In the second case, they would not be
  17569. visible to any other modules.
  17570.   So in that context, static means "local".  This applies to functions as
  17571. well as variables.  The other context is similar, inside a function, where
  17572. static makes the variable (already local to the function) "global" in the
  17573. sense that it does not change between invocations of the function - but it
  17574. is still hidden (this is known as scoping as in the "scope" of a
  17575. definition).
  17576. ---------------
  17577. Following thread
  17578.  
  17579. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AHI1793 Date: 06/13/90
  17580. From: GREGORY WILSON                                        Time: 02:29 pm
  17581.   To: THOMAS ZERUCHA (Rcvd)                                 (Read 71 times)
  17582. Subj: R: SIMPLE 'C' QUESTION
  17583.  
  17584. Thanks for clearing it up for me! Makes sense!
  17585. Gregory Wilson
  17586. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  17587.  
  17588. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AHH3356 Date: 06/13/90
  17589. From: ANDY HUBBELL                                          Time: 01:55 pm
  17590.   To: ALL                                                   (Read 71 times)
  17591. Subj: MICROSOFT C VERSION 6.0 USERS...
  17592.  
  17593. I will be brief and to the point.  I have been asked to develop some code
  17594. using MSC v6.0.  I have done a little work with Turbo C but I still call
  17595. myself as a novice.  What I nedd to know is this; Is there anyone out there
  17596. or who might be reading this that wouldn't mind answering a few dumb
  17597. questions once and while on this BBS?
  17598.  
  17599. If anyone wants to take a stab at one now, here it is.
  17600.  
  17601. I was converting Turbo C source to MSC source and I replaced at GOTOXY
  17602. (TC) routine with what I thought was the equivalent SETTEXTPOSITION (MSC).
  17603.  I can compile fine but when I go to link I get an 'unresolved external'
  17604. error.  I have included graph.h which the book says must be included.
  17605.  
  17606. If anyone can help or you need more details please write.
  17607.  
  17608. andy
  17609. ---------------
  17610. Following thread
  17611.  
  17612. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AHP2207 Date: 06/13/90
  17613. From: CHAD GIBBONS                                          Time: 08:36 pm
  17614.   To: ANDY HUBBELL (Rcvd)                                   (Read 73 times)
  17615. Subj: R: MICROSOFT C VERSION 6.0 USERS...
  17616.  
  17617. Apparently, GRAPHICS.LIB was not included as a default library when your
  17618. system libraries were built.  You have two choices: either reinstall,
  17619. making sure GRAPHICS.LIB is included, or in the link phase explicitly use
  17620. GRAPHICS.LIB as an extra library.
  17621. ---------------
  17622. ** Current thread: MICROSOFT C VERSION 6.0 USERS...
  17623.  
  17624. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AIG1026 Date: 06/14/90
  17625. From: ANDY HUBBELL                                          Time: 12:17 pm
  17626.   To: CHAD GIBBONS (Rcvd)                                   (Read 71 times)
  17627. Subj: R: MICROSOFT C VERSION 6.0 USERS...
  17628.  
  17629. thanks Chad, I will give it a shot....
  17630. ---------------
  17631. ** Current thread: MICROSOFT C VERSION 6.0 USERS...
  17632.  
  17633. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AIN2495 Date: 06/14/90
  17634. From: GRANT ELLSWORTH (Leader)                              Time: 07:41 pm
  17635.   To: ANDY HUBBELL (Rcvd)                                   (Read 71 times)
  17636. Subj: R: MICROSOFT C VERSION 6.0 USERS...
  17637.  
  17638. Try including GRAPH.LIB (or some such name) in the linker library specifi-
  17639. cation.  Including <Graph.h> just assures that the protoytype header will
  17640. be included which , in turn, assures that the parameters for the calling
  17641. sequence will be generated correctly.
  17642. ---------------
  17643. ** Current thread: MICROSOFT C VERSION 6.0 USERS...
  17644.  
  17645. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AJL2346 Date: 06/15/90
  17646. From: RON FOX                                               Time: 05:39 pm
  17647.   To: ANDY HUBBELL (Rcvd)                                   (Read 73 times)
  17648. Subj: R: MICROSOFT C VERSION 6.0 USERS...
  17649.  
  17650. Andy
  17651. The function is _settextposition, the underscore is part of the function
  17652. name.  Also, it is necessary to use lower case letters.  Most of the time
  17653. case sensitivity is enforced.
  17654. If you installed the graphics library as part of the combined libraries,
  17655. it is not necessary to include graphics.lib when linking.
  17656. Hope that this helps.
  17657. Ron
  17658. ---------------
  17659. ** Current thread: MICROSOFT C VERSION 6.0 USERS...
  17660.  
  17661. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AIE0531 Date: 06/14/90
  17662. From: LARRY MACNEILL                                        Time: 10:08 am
  17663.   To: ALL                                                   (Read 69 times)
  17664. Subj: YACC AND LEX
  17665.  
  17666. Does anyone have suggestions for learning something about yacc and lex?
  17667. Bison from the Free Software Foundation and Lex from the C Users' Group
  17668. have the code but precious little in the way of using them.  Since they
  17669. are such ubiquitous utilities on Unix systems, maybe their use is common
  17670. knowledge but not to me.  I got an advertisement in the mail about the
  17671. book, Crafting a Compiler, which says it emphasizes the practical aspects
  17672. of writing a compiler.  That could mean how to use lex and yacc but I've
  17673. never seen the book.  Does anyone have suggestions or comments?
  17674. ---------------
  17675.  
  17676. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AJC2444 Date: 06/15/90
  17677. From: DENNIS DODSON                                         Time: 08:40 am
  17678.   To: ALL                                                   (Read 73 times)
  17679. Subj: LASERJET
  17680.  
  17681. Hope someone can help.  Converting to a HP LaserJet III from dot matrix.
  17682. Wrote C program to automate changing of printer settings instead of using
  17683. the LaserJet's manual console commands to allow a .bat file to print
  17684. output from daily runs (have pause to allow previous printing to finish
  17685. before accessing with C program).  Using straight DOS Print command to
  17686. print individual files to laser in the .bat file.  My requirements are
  17687. to have the ability to set 1) 6 or 8 lpi and 2) Condensed 'on' or 'off'.
  17688. Seems to be working ok except where I have to send a 'Number' like 66
  17689. or 88 as a parameter for lines/page.
  17690.  
  17691. In the following sample code (line #7) to set the printer to 8lpi, what
  17692. should I be entering instead of the ???'s to indicate the number 88?
  17693. Or is my syntax completely wrong, or do you have any other ideas you
  17694. can share with me?  Or should I be issuing additional commands to
  17695. accomplish my goal (pitch, point, font, etc.)?  All I want the LaserJet
  17696. to do is print standard data processing line printer-like documents,
  17697. nothing fancy.
  17698.  
  17699. main( int argc, char *argv[] )
  17700. {
  17701.      if (strncmp(argv[1], "8lpi", 4) == 0 ||
  17702.        strncmp(argv[1], "8LPI", 4) == 0)
  17703.      {
  17704.           fprintf(stdprn, "\x1b\x26\x6c\x38\x44"); /* 8 lines/inch
  17705. */
  17706.           fprintf(stdprn, "\x1b\x26\x6c\???\x50"); /* page length to 88
  17707. */
  17708.           fprintf(stdprn, "\x1b\x26\x6c\x32\x41"); /* page size to letter
  17709. */
  17710.           printf("LaserJet Set to 8 Lines/Inch");
  17711.           exit(0);
  17712.      }
  17713.  
  17714. Dennis...
  17715. ---------------
  17716. Following thread
  17717.  
  17718. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AKS0865 Date: 06/16/90
  17719. From: OTTO PORTER                                           Time: 11:14 pm
  17720.   To: DENNIS DODSON (Rcvd)                                  (Read 69 times)
  17721. Subj: R: LASERJET
  17722.  
  17723. This may seem strange (it did to me) but you have to use the ASCII
  17724. equivalent character for the DECIMAL number you are trying to use.
  17725. i.e.  your \??? would be replaced with \X (ASCII X(upper case) = Dec 88).
  17726. You may be able to use the hex equivalent but if memory serves I
  17727. doubt it.  I used to do a lot of laser jet support and I seem to remember
  17728. that it was very picky about getting the exact representation listed
  17729. in their reference.
  17730. Hope this helps.
  17731.  
  17732. Otto Porter
  17733. ---------------
  17734. ** Current thread: LASERJET
  17735.  
  17736. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AME2225 Date: 06/18/90
  17737. From: DENNIS DODSON                                         Time: 10:37 am
  17738.   To: OTTO PORTER (Rcvd)                                    (Read 67 times)
  17739. Subj: R: LASERJET
  17740.  
  17741. Thanks Otto, the ASCII equivalent character works fine.  Yes, I did try
  17742. the hex equivalent before sending the message and that DID NOT work
  17743. as you could recall.  Thanks again for the help.
  17744.  
  17745. Dennis Dodson
  17746. ---------------
  17747. ** Current thread: LASERJET
  17748.  
  17749. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3ANB1096 Date: 06/19/90
  17750. From: VICTOR DURA                                           Time: 07:18 am
  17751.   To: DENNIS DODSON (Rcvd)                                  (Read 67 times)
  17752. Subj: R: LASERJET
  17753.  
  17754. Dennis:
  17755.   The following works for me using a MSC 4.0 compiler.
  17756. main( int argc, char *argv[] )
  17757. {
  17758.    if (strnicmp(argv[1], "8lpi", 4) == 0 ) /* case insensitive cmp */
  17759.    {
  17760.         fprintf(stdprn, "\027&l8D"); /* 8 lines/inch         */
  17761.         fprintf(stdprn, "\027&l88P"); /* page length to 88   */
  17762.         fprintf(stdprn, "\027&l2A"); /* page size to letter  */
  17763.         printf("LaserJet Set to 8 Lines/Inch");
  17764.         exit(0);
  17765.    }
  17766. }
  17767. Note that I only need to use the "\" to get the escape character in
  17768. the string. Of course you can use the "\" introducer to define
  17769. each individual character, but it's not needed and I think it's more
  17770. confusing.
  17771. Hope this helps...
  17772. Vic Dura
  17773.  
  17774. ---------------
  17775. ** Current thread: LASERJET
  17776.  
  17777. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3ARI1290 Date: 06/22/90
  17778. From: DENNIS DODSON                                         Time: 02:21 pm
  17779.   To: VICTOR DURA (Rcvd)                                    (Read 65 times)
  17780. Subj: R: LASERJET
  17781.  
  17782. Thanks Vic, I think too that it is less confusing in that is more like
  17783. the commands explained in the HP users manual.  When I have a need to
  17784. modify my program for additional printer commands I will convert to the
  17785. more understandable command string you suggested.  You enlightened me
  17786. also with the case insensitve 'strnicmp' (never have time to RTFM!).
  17787. Thanks again for your help.
  17788. Dennis.
  17789. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  17790.  
  17791. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AKI0123 Date: 06/16/90
  17792. From: MICHAEL MCCLUNE                                       Time: 02:02 pm
  17793.   To: ALL                                                   (Read 69 times)
  17794. Subj: TC++ OFFER
  17795.  
  17796. In todays mail I recieved a coupon  Borland offering TC++ Pro
  17797. for $179.95. Is this a good deal? Would someone like to take a whack at
  17798. convincing me that Boredom's products are any better than it's
  17799. competitors products?
  17800.  
  17801. Your Serve
  17802. ---------------
  17803. Following thread
  17804.  
  17805. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3ALH3081 Date: 06/17/90
  17806. From: GRANT ELLSWORTH (Leader)                              Time: 01:51 pm
  17807.   To: MICHAEL MCCLUNE (Rcvd)                                (Read 70 times)
  17808. Subj: R: TC++ OFFER
  17809.  
  17810. If you don't now own TC2.0 propak, you might still get a better price than
  17811. $179 for the tc++ propak ... e.g. Programmer's Connection is offering the
  17812. same box for $159 and can probably get it to you faster.
  17813.  
  17814. With the suggest list price for TC++ propak at $299, $159 and $179 are
  17815. "good deals".
  17816.  
  17817. Now,  as to the more fundamental question of whether Borland's TC++ with
  17818. the "embedded" ansi-c compliant compiler is "better than its competitors",
  17819. anybody's answer,, INCLUDING MINE, will have some predjudices and bigotry
  17820. attached.  OK, with that in mind and with some regard  to best street
  17821. prices available, I regard Borland's language products, specifically the
  17822. C and probably (haven't received my copy yet) c++ products, are at least
  17823. "competitive" with those of other vendors.  Now, here is my key point (and
  17824. "predjudice"):  At any price for any of the several C compilers and the 2
  17825. C++ (Zortech has the other), each is better than the Microsoft offering
  17826. in one or more respects.  On past performance and my own experience, I've
  17827. found the Watcom C and the Borland C compilers the most reliable and bug
  17828. free of the 4 I've done anything with.  But, that's not to say I've not
  17829. had some problems with those --- I have.  It's been my experience, and
  17830. therefore, my opinion, that Microsoft cannnot build and sell a reliable
  17831. language product, with the possible exception of the assembler --- and
  17832. there have been some more sophisticated 80x86 assemblers.  Grant
  17833. ---------------
  17834. ** Current thread: TC++ OFFER
  17835.  
  17836. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3ALL2495 Date: 06/17/90
  17837. From: MICHAEL MCCLUNE                                       Time: 05:41 pm
  17838.   To: GRANT ELLSWORTH (Rcvd)                                (Read 70 times)
  17839. Subj: R: TC++ OFFER
  17840.  
  17841. Grant,
  17842. Thank you for the reply. I am currently using the MS QC 2.5 compiler
  17843. with Quick assembler. The only real complaint I would have is the lack
  17844. of what TC calls is VAROOM, once QC is out of space its on to the
  17845. command line then back to the editor and then no debugger outside
  17846. the QC environment. This gets to be quite frustrating. I'm sure you've
  17847. experienced frustration before.
  17848. Mike
  17849. ---------------
  17850. ** Current thread: TC++ OFFER
  17851.  
  17852. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3ALP3541 Date: 06/17/90
  17853. From: GRANT ELLSWORTH (Leader)                              Time: 08:59 pm
  17854.   To: MICHAEL MCCLUNE (Rcvd)                                (Read 70 times)
  17855. Subj: R: TC++ OFFER
  17856.  
  17857. Mike, M$C5.1 and 6.0 (full boat) come with the CV debugger --- which is a
  17858. stand-alone debugger.  Before BOrland's TD, CV was the best (and only)
  17859. alternative to dos's DEBUG and its close cousin, SYMDEB.  Over those, CV
  17860. was quite  an improvement.  TD is an exponential improvement over CV as
  17861. distributed in M$C5.1 --- but I can't comment on MS's 6.0 CV offering
  17862. since I haven't tried to use it.  Anyway, while it may cost more $$ than
  17863. it's really worth, upgrading from QC2.5 to the full M$C 6.0 boat may be
  17864. less expensive than getting a fresh version of TC++ ProPak --- and you'll
  17865. probably pay for more than the difference in you time chasing down obscure
  17866. bugs created by the compiler ...  Grant
  17867. ---------------
  17868. ** Current thread: TC++ OFFER
  17869.  
  17870. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AMN2052 Date: 06/18/90
  17871. From: MICHAEL MCCLUNE                                       Time: 07:34 pm
  17872.   To: GRANT ELLSWORTH (Rcvd)                                (Read 71 times)
  17873. Subj: R: TC++ OFFER
  17874.  
  17875. Grant
  17876. Seems this C++ subject has created quite a stir in this conference!
  17877. I appreciate your responce and advice in this matter. I was unaware
  17878. that I could upgrade my QC2.5 to MSC6.0 looks like a call to
  17879. Redmond WA is in order. Do you know if M$ has a C++ in the works?
  17880. Your Serve
  17881. ---------------
  17882. ** Current thread: TC++ OFFER
  17883.  
  17884. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AMQ0159 Date: 06/18/90
  17885. From: CRAIG SMITH                                           Time: 09:02 pm
  17886.   To: GRANT ELLSWORTH (Rcvd)                                (Read 71 times)
  17887. Subj: R: TC++ OFFER
  17888.  
  17889. I can comment on 6.0 CodeView.  I find it amazing that Microsoft can
  17890. revise its compiler so many times (3 times since version 4.0) and yet
  17891. leave its premier debugger untouched.  Borland's TD left it in the dust on
  17892. its first release and the gap has increased with every new version.
  17893.  
  17894. Some major advantages are:
  17895.     1)  Vastly superior user interface
  17896.     2)  Support for 386 debugging (rivaling hardware debuggers)
  17897.     3)  Support for remote debugging with a second computer
  17898.     4)  Reverse execution allows you to step backwards through code
  17899.     5)  Small size
  17900.  
  17901. Codeview misses on all of these points.
  17902.  
  17903. Even though I use both Borland and Microsoft C compilers, I have retired
  17904. Codeview (6.0 and earlier) from my hard disk and use only Turbo Debugger.
  17905.  
  17906. ---------------
  17907. ** Current thread: TC++ OFFER
  17908.  
  17909. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3ANN3122 Date: 06/19/90
  17910. From: GRANT ELLSWORTH (Leader)                              Time: 07:52 pm
  17911.   To: MICHAEL MCCLUNE (Rcvd)                                (Read 71 times)
  17912. Subj: R: TC++ OFFER
  17913.  
  17914. Mike, 3 points :
  17915.  
  17916. o I was speculating that MS really has an upgrade policy for qc2.5 to a
  17917.   full boat M$C 6.0; I believe MS should ... it would be uncharacteristic
  17918.   if they did not ... so a call to them would be in order if you are
  17919.   interested in M$ C 6.0
  17920.  
  17921. o I would find it difficult to believe that M$ did not have some kind of
  17922.   C++ implementation in the works
  17923.  
  17924.   If they don't and Borland's TC++ proves itself as a serious production
  17925.   compiler to the point where it costs M$C in prestige as THE serious
  17926.   MSDOS/PC production C compiler, then they surely will
  17927.  
  17928.   Seems to me that M$ is betting on Windows 3 and OS/2 P.M. access as
  17929.   being the critcal selling points for their C compiler system
  17930.  
  17931.   However, the slow acceptance and expansion of the OS/2 base AND the
  17932.   alleged limitations of Windows 3.0 as a multi-tasker (against DV)
  17933.   and some other problems in adaptability/flexibility, may make those
  17934.   selling points non-issues --- especially if Quarterdeck comes out
  17935.   with an X-Windows compatible variation later this year, as is rumored
  17936.  
  17937.   I also read that there are many problems and glitches with the Pro-
  17938.   grammer's WorkBench delivered with the M$C 6.0 package === and that
  17939.   will drive folks who want that right to Scotts Valley (home of BI)
  17940.  
  17941. o Although this OOP idea in C++ is the current rage (and rave) among
  17942.   the "leading-edge" programmers-technologists, I'm wondering whether
  17943.   it (OOP) will really catch on as an industry-wide programming device
  17944.  
  17945.   The technology WOULD be good to know about, since would probably help
  17946.   regular non-OOP programmers to become more organized and careful in
  17947.   their implementations
  17948.  
  17949.   While I can't claim any expertise in C++ (I just started reading about
  17950.   it 3 months ago), I have determined that it is a nice instrument for
  17951.   imposing discipline on my thinking
  17952.  
  17953. The key point to keep in mind is that BI, again, has made an important
  17954. programming tool (c++) accessible and affordable to the hobbyist and
  17955. independent researcher --- and THAT ALONE will assure some expanded use!
  17956.  
  17957. Anyway, if I were you, I'd find out how much it would cost to "upgrade"
  17958. to 6.0 and compare that to the best mail-order price for the TC++ ProPak.
  17959.  
  17960. See Craig Smith's message of 6/18 comparing the CV and TD products.  It
  17961. may well be that TD is worth the price of the whole ProPak in terms of
  17962. its value to the programmer/developer.
  17963.  
  17964. For my part, I'm going to be getting the upgrade from Watcom C 7.0 (286)
  17965. to Watcom C 8.0 (286) --- for use in my rare cpu-intensive routines.  I
  17966. read that the Watcom Debugger, WVIDEO, is at least halfway between CV and
  17967. TD in terms of it usability --- that'll be interesting to check out.
  17968. I make lots of dumb coding (and design <sigh>) mistakes that a good
  17969. debugger can help me find.  The debuggers get a real shakedown when
  17970. I go near code --- seems that the moment I even look at some, it gets
  17971. insect infested!
  17972.  
  17973. A good compiler is not worth much unless there is a good debugger handy
  17974. which can be used with it effectively.
  17975.  
  17976. Grant
  17977. ---------------
  17978. ** Current thread: TC++ OFFER
  17979.  
  17980. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3ANP0861 Date: 06/19/90
  17981. From: MICHAEL MCCLUNE                                       Time: 08:14 pm
  17982.   To: GRANT ELLSWORTH (Rcvd)                                (Read 68 times)
  17983. Subj: R: TC++ OFFER
  17984.  
  17985. Grant
  17986. When I get near code I find it usefull to have a can of Raid handy.
  17987. But then I'm just a dungeon programmer. Lots of bugs in this
  17988. basement besides the living kind. I've been in this horrible slump
  17989. lately. What do you do to cure this malady?
  17990. BTW I enjoyed reading your reply to my reply to your reply......
  17991. Mike
  17992. ---------------
  17993. ** Current thread: TC++ OFFER
  17994.  
  17995. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3APL0564 Date: 06/20/90
  17996. From: GRANT ELLSWORTH (Leader)                              Time: 05:09 pm
  17997.   To: MICHAEL MCCLUNE (Rcvd)                                (Read 71 times)
  17998. Subj: R: TC++ OFFER
  17999.  
  18000. To cure the malady ... hmmmm ... I find activity which puts my head 1
  18001. parsec away from these electronic algorithm parsers very helpful ...
  18002. e.g. pulling weeds, trimming the bushes, planting new  bushes, getting
  18003. the soil under the fingernails, sawing wood for shelving and bookcases,
  18004. and other such varients.  May not be a real cure, but it sure refreshes
  18005. the stale brain ...
  18006. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  18007.  
  18008. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AMF2747 Date: 06/18/90
  18009. From: GREGORY WILSON                                        Time: 11:45 am
  18010.   To: ALL                                                   (Read 71 times)
  18011. Subj: C++
  18012.  
  18013. Could someone tell me in 500 words or less what the advantage is in using
  18014. C++ over C.
  18015. Is it more portable?
  18016. Is it faster?
  18017. Will regular C programs compile under C++ compilers?
  18018. Are there any standards in place for C++?
  18019. Is MSC planning on adding C++ to their product?
  18020. Now that I finnaly have a handle on C, is it worth my time to learn C++?
  18021.  
  18022. I would appreciate any information you could give.
  18023. Thanks in advance!!
  18024. Gregory Wilson
  18025. ---------------
  18026.  
  18027. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AMK2801 Date: 06/18/90
  18028. From: GABE CECI                                             Time: 04:46 pm
  18029.   To: ALL                                                   (Read 71 times)
  18030. Subj: BORLAND C++
  18031.  
  18032. I just received an offer from Borland to buy their latest C++ package
  18033. ($179 for professional package, $99 for regular package).
  18034.  
  18035. Any comments about the quality of the software and the value of the offer?
  18036.  
  18037. I do not currently do any programming in C or C+, but have an interest in
  18038. learning the newest programming languages.
  18039. Gabe.
  18040. ---------------
  18041. Following thread
  18042.  
  18043. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AML1379 Date: 06/18/90
  18044. From: GRANT ELLSWORTH (Leader)                              Time: 05:23 pm
  18045.   To: GABE CECI (Rcvd)                                      (Read 71 times)
  18046. Subj: R: BORLAND C++
  18047.  
  18048. Gabe, see previous messages in conference - search on subject: TC++ OFFER
  18049.  
  18050. I had a discussion with another one of our correspondents on this subject.
  18051.  
  18052. Leave message if you have any further questions after scanning the recent
  18053. threads on c++/TC++ (since May 14-15).  Grant
  18054. ---------------
  18055. ** Current thread: BORLAND C++
  18056.  
  18057. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AMS0949 Date: 06/18/90
  18058. From: GABE CECI                                             Time: 11:15 pm
  18059.   To: GRANT ELLSWORTH (Rcvd)                                (Read 70 times)
  18060. Subj: R: BORLAND C++
  18061.  
  18062. Thanks - I did scan the messages and see that the upgrade prices may not
  18063. be the best deal.  In my case, I would not be upgrading.  Borland made me
  18064. the offer because I have stayed with the upgrades in Turbo Pascal.
  18065.  
  18066. Notice you're from Maryland - spent some of my favorite years in Baltimore
  18067. (college days) and got to visit around the state during holidays when I
  18068. leached off my buddies.  By chance are you a lacrosse fan?
  18069. Gabe.
  18070. ---------------
  18071. ** Current thread: BORLAND C++
  18072.  
  18073. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3ANN3389 Date: 06/19/90
  18074. From: GRANT ELLSWORTH (Leader)                              Time: 07:56 pm
  18075.   To: GABE CECI (Rcvd)                                      (Read 68 times)
  18076. Subj: R: BORLAND C++
  18077.  
  18078. Gabe, When I was at UMCP, LaCrosse had not yet gotten an official
  18079. standing.  It wasn't until several years later that the UM group was
  18080. pushing it and trying to get attendence.  I saw one game, though.  It's
  18081. fast and rough.  Grant
  18082. ---------------
  18083. ** Current thread: BORLAND C++
  18084.  
  18085. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3ANQ0323 Date: 06/19/90
  18086. From: GABE CECI                                             Time: 09:05 pm
  18087.   To: GRANT ELLSWORTH (Rcvd)                                (Read 67 times)
  18088. Subj: R: BORLAND C++
  18089.  
  18090. RE: lacrosse is fast and rough - that's what I heard about C programming -
  18091. the programs run fast and they're rough to write.
  18092. Gabe.
  18093. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  18094.  
  18095. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AMN1249 Date: 06/18/90
  18096. From: DAN HAYNES                                            Time: 07:20 pm
  18097.   To: ALL                                                   (Read 75 times)
  18098. Subj: TURBO C++
  18099.  
  18100. Hey, I have entered premature panic driven mode with Turbo C++. I ordered
  18101. the upgrade, but a professor at the university graciously loaned me his
  18102. disks so I could install and play. Seems as though it barfs on perfectly
  18103. good C code, coming up with messages about redefining argument types and
  18104. argument type mismatches. I caught a couple where the paramaters to a
  18105. function were named "new" which seems reasonable enough, but I've got some
  18106. others that pass through Turbo C 2.0, Microsoft C 5.1 and Gimpel PC Lint
  18107. 4.0 without a problem, but caused fatal errors under Turbo C++. I know I
  18108. should relax and wait for the manuals to arrive and see if my installation
  18109. is correct, but being the impatient *** I am... anyone else having similar
  18110. fun??
  18111.       Dan Haynes
  18112. ---------------
  18113. Following thread
  18114.  
  18115. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AMP3472 Date: 06/18/90
  18116. From: JOSEPH KARAS                                          Time: 08:57 pm
  18117.   To: DAN HAYNES (Rcvd)                                     (Read 72 times)
  18118. Subj: R: TURBO C++
  18119.  
  18120. Could you please give some examples, I've recompiled code and have had
  18121. no problems so far.  One of my commercial libs had some problems but
  18122. this was due to some NON-ANSI code.
  18123. ---------------
  18124. ** Current thread: TURBO C++
  18125.  
  18126. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AMR2159 Date: 06/18/90
  18127. From: ROBERT BALSOVER                                       Time: 10:36 pm
  18128.   To: DAN HAYNES (Rcvd)                                     (Read 69 times)
  18129. Subj: R: TURBO C++
  18130.  
  18131. Dan,
  18132.      It needs the proper prototypes so that the C++ compiler can compile
  18133. programs that use polymorphism.  What that means is that you can have more
  18134. than one function with different arg lists and the compiler knows which
  18135. one you want because of the parms that you pass the function.  This
  18136. feature improves readability.  A example would be:
  18137. complex sqrt(complex i);
  18138. bcd sqrt(bcd i);
  18139. double sqrt(double i);
  18140. All three functions have the same name but the compiler can tell which one
  18141. you really wish to call because of what you pass the function.
  18142.      Also, you could look at it from the other side, the other compilers
  18143. accept the code without warning or error because of less type checking,
  18144. but its much easier to catch bugs with TC++ than TC because of the
  18145. stronger type checking.  Next time your tracking down bugs think about it,
  18146. you might not think its a bad idea.
  18147. Bob
  18148. ---------------
  18149. ** Current thread: TURBO C++
  18150.  
  18151. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3ANJ3219 Date: 06/19/90
  18152. From: ALEX FIORE                                            Time: 03:53 pm
  18153.   To: DAN HAYNES (Rcvd)                                     (Read 70 times)
  18154. Subj: R: TURBO C++
  18155.  
  18156. DH> Seems as though it barfs on perfectly good C code, coming up with
  18157. DH> messages about redefining argument types and argument type mismatches.
  18158.         .
  18159. Your using the C++ compiler instead of the ANSI C compiler.  C++ is much
  18160. more selective about function parameter types than C.  It has to be
  18161. because
  18162. it will allow several functions with the same name, and the only
  18163. distinction
  18164. is the difference in argument types.
  18165.         .
  18166. DH> I caught a couple where the paramaters to a function were named "new"
  18167. DH> which seems reasonable enough.
  18168.  
  18169. Again your using the C++ compiler instead of ANSI C. "new" is an operator
  18170. in C++ that functions like malloc. You must go into
  18171. Options/Compiler/Source
  18172. to select ANSI C source instead of C++ source code input.
  18173.         .
  18174. Hope you enjoy the manuals when they arrive!
  18175.                         Alex Fiore
  18176.  
  18177.  
  18178. ---------------
  18179. ** Current thread: TURBO C++
  18180.  
  18181. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AQR3095 Date: 06/21/90
  18182. From: DAN HAYNES                                            Time: 10:51 pm
  18183.   To: ALL                                                   (Read 71 times)
  18184. Subj: TURBO C++
  18185.  
  18186. Whoops, I forgot to capture the last message in the thread, so this
  18187. will probably start a new one, but I'm leaving town for 4 days and
  18188. I is in a hurry! Anyway, my problems with turbo C++ are really quite
  18189. trival, almost. I still haven't gotten the manuals yet (first time its
  18190. actually taken Borland more than 2 of the 3 weeks promised delivery to
  18191. get something to me!)  I should have mentioned in my other posting that
  18192. I was aware of the requirement for prototypes under C++ etc. The problem
  18193. I have is that standard C function declarations that are preceeded by a
  18194. prototype are randomly picked for errors (I think). Examples
  18195. extern int foobar( int goo ) ;
  18196. int foobar( goo )
  18197. int goo ;
  18198. {
  18199.     puts( "I'm Gumby dammit" ) ;
  18200. }
  18201.  
  18202.  In a file containing about 15 such declarations, only one function was
  18203. selected for a redeclaration of function foobar - different types for goo
  18204. error.  It happened to me again today while I was porting PC Curses to
  18205. Turbo. This really wouldn't be a major problem except that the code I
  18206. originally discovered the error with is the PD C compiler from the Amiga.
  18207. I have ported it to MS-DOS and am in the process of converting it from
  18208. 68k code generation to native mode 386 code generation, and if I have to
  18209. change to above declaration to "int foobar( int goo ) {}" then it will no
  18210. longer be able to compiler itself, unless I make it Ansi too. (I'm not
  18211. THAT ambitious!)         ^ scratch that r please, sticky fingers...
  18212.         Dan
  18213. ---------------
  18214. ** Current thread: TURBO C++
  18215.  
  18216. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3ARL3581 Date: 06/22/90
  18217. From: GRANT ELLSWORTH (Leader)                              Time: 05:59 pm
  18218.   To: DAN HAYNES (Rcvd)                                     (Read 68 times)
  18219. Subj: R: TURBO C++
  18220.  
  18221. What you probably need is a "K+R" to Ansi C translator.  Anybody care to
  18222. recommend one?
  18223. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  18224.  
  18225. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AND2699 Date: 06/19/90
  18226. From: HYONG BANG                                            Time: 09:45 am
  18227.   To: ALL                                                   (Read 67 times)
  18228. Subj: PROGRAMMING UNDER WINDOWS
  18229.  
  18230. Message CC'd to:
  18231.      ALL
  18232.      GRANT ELLSWORTH
  18233.  
  18234. Is there a Windows API kit or some such equivalent to allow us TC/TC++
  18235. users to program MS Windows 3.0?
  18236.  
  18237. Hyong
  18238. P.S. Anyone here have programming experience with Actor?
  18239. ---------------
  18240. Following thread
  18241.  
  18242. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3ANG1468 Date: 06/19/90
  18243. From: GRANT ELLSWORTH (Leader)                              Time: 12:24 pm
  18244.   To: HYONG BANG (Rcvd)                                     (Read 69 times)
  18245. Subj: R: PROGRAMMING UNDER WINDOWS
  18246.  
  18247. There is a Windows 3.0 developers' tool kit.     But, I don't think you
  18248. can use it with the BOrland Languages at this time.  Rumor has it that BI
  18249. is working on an extention to TC++ which will be able to talk directly to
  18250. the Windows 3.0 environmemt --- but, rumors are rumors.  Grant
  18251. ---------------
  18252. ** Current thread: PROGRAMMING UNDER WINDOWS
  18253.  
  18254. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3ASE3258 Date: 06/23/90
  18255. From: HYONG BANG                                            Time: 10:54 am
  18256.   To: GRANT ELLSWORTH (Rcvd)                                (Read 65 times)
  18257. Subj: R: PROGRAMMING UNDER WINDOWS
  18258.  
  18259. I was afraid of that...but more and more companies (like mine) are ending
  18260. up dependent on a windows app.
  18261.  
  18262. Oh, well..... Thanks,
  18263. Hyong
  18264. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  18265.  
  18266. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AP11411 Date: 06/20/90
  18267. From: THOMAS NOFSINGER                                      Time: 12:23 am
  18268.   To: ALL                                                   (Read 67 times)
  18269. Subj: ASM DEVICE DRIVER
  18270.  
  18271. Help, I am looking for an ASM programmer to convert a TSR program into a
  18272. device driver; this is a for pay deal.  If you are interested, please
  18273. leave me a personal e-mail messge on this BBS.  Thomas Nofsiger.
  18274. ---------------
  18275.  
  18276. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3APN1464 Date: 06/20/90
  18277. From: MICHAEL MCCLUNE                                       Time: 07:24 pm
  18278.   To: GRANT ELLSWORTH (Rcvd)                                (Read 72 times)
  18279. Subj: MS & WHO
  18280.  
  18281. Grant
  18282. I feel we've exauhsted the tc++ thing so why not start a new subject.
  18283. Remember my last message about calling M$ about the upgrade from my
  18284. QC 2.5. Well I did they don't!!! There is no policy in place for an
  18285. upgrade from QC to M$C 6.0. M$ is not working on a C++ compiler however
  18286. they have under their wing another vendor that has a C++ interpreter for
  18287. C 6.0. On the DOS platform the cost is $499.00. By this time your
  18288. wondering about the subject title well the name M$ is affiliated with is
  18289. Glockenspiel?? If anyone reading this is interested the number is
  18290. 1-800-462-4374. Forgot to ask where there located.
  18291. You were also correct in your assumption that M$ is banking on the
  18292. Windows 3.0 as an OOP development system along with C 6.0 and
  18293. Glockenspiels?? C++.
  18294. BTW I not sure about the word interpreter used above it may have been
  18295. something else but it did not sound like a stand alone compiler, on
  18296. the other hand I may have misunderstood the person at Glockenspiel
  18297. I talked to.
  18298. ---------------
  18299. Following thread
  18300.  
  18301. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3APS1924 Date: 06/20/90
  18302. From: ROBERT BALSOVER                                       Time: 11:32 pm
  18303.   To: MICHAEL MCCLUNE (Rcvd)                                (Read 70 times)
  18304. Subj: R: MS & WHO
  18305.  
  18306. Michael,
  18307.      I believe its a translator, which means it takes C++ source and
  18308. converts it to C source.  They are a known product, and I've been told
  18309. it's slow in operation.  I've been told that the M$ workbench is very slow
  18310. on a dos machine, that along with the speed of the M$C compiler and
  18311. Glockenspiel's translator doesn't sound like a very productive group of
  18312. tools for DOS programming.  Once again I believe M$ has taken the lazy way
  18313. out and relied on hardware speed to make their products look good.  I kind
  18314. of expected them to farm out their C++ approach like they did with Quick
  18315. Pascal.
  18316.      If anyone does get this product, I'd like to know your impression.
  18317. Bob
  18318. ---------------
  18319. ** Current thread: MS & WHO
  18320.  
  18321. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AQN1757 Date: 06/21/90
  18322. From: GRANT ELLSWORTH (Leader)                              Time: 07:29 pm
  18323.   To: MICHAEL MCCLUNE (Rcvd)                                (Read 68 times)
  18324. Subj: R: MS & WHO
  18325.  
  18326. Well, it does look like M$ is going to provide some kind of C++ support
  18327. or access === and a front-end preprocessor is not unheard of.  Seems that
  18328. ATT had something like that available when they "defined" a C++ super-
  18329. set to standard C.  You probably heard the Glockenspiel rep talking about
  18330. something of that sort.  Grant
  18331. ---------------
  18332. ** Current thread: MS & WHO
  18333.  
  18334. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AQN2118 Date: 06/21/90
  18335. From: GRANT ELLSWORTH (Leader)                              Time: 07:35 pm
  18336.   To: ROBERT BALSOVER (Rcvd)                                (Read 68 times)
  18337. Subj: R: MS & WHO
  18338.  
  18339. Reads like M$ amd IBM are really getting their act in concert!  IBM has
  18340. LONG had the philosophy that slowing down or kludging up the software
  18341. was quite the thing to do --- as long as it resulted in the customers
  18342. buying bigger, faster, more expen$ive hardware in even greater quantities.
  18343. It is indeed a perfect match.  Grant
  18344. ---------------
  18345. ** Current thread: MS & WHO
  18346.  
  18347. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AQP1040 Date: 06/21/90
  18348. From: MICHAEL MCCLUNE                                       Time: 08:17 pm
  18349.   To: ROBERT BALSOVER (Rcvd)                                (Read 68 times)
  18350. Subj: R: MS & WHO
  18351.  
  18352. Bob
  18353. Programmers workbench is slow on anything less than a 386, according to
  18354. a friend of mine who is a professional programmer. He did say that M$
  18355. has an option for aggressive optimization, really packs the code as long
  18356. as the user is the conservative type and could really destroy a program
  18357. poorly written.
  18358. Glockenspiel is going to send me some info on their product, more to
  18359. follow.
  18360. ---------------
  18361. ** Current thread: MS & WHO
  18362.  
  18363. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AQP1587 Date: 06/21/90
  18364. From: MICHAEL MCCLUNE                                       Time: 08:26 pm
  18365.   To: GRANT ELLSWORTH (Rcvd)                                (Read 70 times)
  18366. Subj: R: MS & WHO
  18367.  
  18368. Grant
  18369. Yes it sounded to me like Sun and Unix systems are the main target of
  18370. the Glockenspiel (isnt that a fun name to type) C++ translater.
  18371. Excuse me Grant while I thank RB for the word I couldnt think of before.
  18372. Thank you Bob.
  18373. ---------------
  18374. ** Current thread: MS & WHO
  18375.  
  18376. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AQS2834 Date: 06/21/90
  18377. From: ROBERT BALSOVER                                       Time: 11:47 pm
  18378.   To: GRANT ELLSWORTH (Rcvd)                                (Read 66 times)
  18379. Subj: R: MS & WHO
  18380.  
  18381. As long as IBM endorses MS-DOS for their PC's, MS will always have that
  18382. cash cow!  Imagine what MS would do if they lost that corner of the
  18383. market, they might actually have to produce competitive products.
  18384. (*Thats a scary thought*).  So anyway, I can see MS being cooperative with
  18385. IBM in that practice.
  18386. Bob
  18387. ---------------
  18388. ** Current thread: MS & WHO
  18389.  
  18390. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3ARG1738 Date: 06/22/90
  18391. From: CHAD GIBBONS                                          Time: 12:28 pm
  18392.   To: ROBERT BALSOVER (Rcvd)                                (Read 68 times)
  18393. Subj: R: MS & WHO
  18394.  
  18395. PC Magazine had a discussion about this---I think it was in Dvorak's
  18396. column.  The Lotus/Novell merger is looking into producing some serious
  18397. heat for MS in the near future.  Novell is close to the only PC based
  18398. company around that could compete with MS for their systems (DOS) market.
  18399. ---------------
  18400. ** Current thread: MS & WHO
  18401.  
  18402. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3ARL2360 Date: 06/22/90
  18403. From: KEN HOPKINSON                                         Time: 05:39 pm
  18404.   To: CHAD GIBBONS (Rcvd)                                   (Read 66 times)
  18405. Subj: R: MS & WHO
  18406.  
  18407. Didn't the Lotus/Novell merger fall through at the last minute?
  18408.  
  18409. KEN
  18410. ---------------
  18411. ** Current thread: MS & WHO
  18412.  
  18413. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3ARL3457 Date: 06/22/90
  18414. From: GRANT ELLSWORTH (Leader)                              Time: 05:57 pm
  18415.   To: MICHAEL MCCLUNE (Rcvd)                                (Read 65 times)
  18416. Subj: R: MS & WHO
  18417.  
  18418. I played the glockenspiel in an orchestra many years ago.  There's a
  18419. "shorter" name for it,,, but, I'm embarassed --- I can't remember what
  18420. it was.  Maybe it was "the bells".  Grant
  18421. ---------------
  18422. ** Current thread: MS & WHO
  18423.  
  18424. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3ARM1178 Date: 06/22/90
  18425. From: ROBERT BALSOVER                                       Time: 06:19 pm
  18426.   To: CHAD GIBBONS (Rcvd)                                   (Read 63 times)
  18427. Subj: R: MS & WHO
  18428.  
  18429. Chad,
  18430.      I'd welcome anyone who could seriously compete against M$, both
  18431. companies would have to be competitive and we, the consumer, would gain
  18432. both better prices and software.
  18433. Bob
  18434. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  18435.  
  18436. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3APP3291 Date: 06/20/90
  18437. From: STEVE BOOTH                                           Time: 08:54 pm
  18438.   To: ALL                                                   (Read 68 times)
  18439. Subj: TC++ SIZE ^SMALL
  18440.  
  18441. Message CC'd to:
  18442.      ALL
  18443.      GRANT ELLSWORTH
  18444.  
  18445. Hi All (and Grant)!
  18446.    Just received my TC++ copy today from Borland.  One item
  18447. that I haven't seen documented was the amount of hard disk
  18448. space required --- just over six megabytes!!
  18449.  
  18450.      Clear the decks (or disks as it were).  This was just for
  18451. Turbo C++ NOT the professional version!
  18452.  
  18453.      Turboing my little heart out...
  18454.      Steve...
  18455. ---------------
  18456. Following thread
  18457.  
  18458. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3APS1536 Date: 06/20/90
  18459. From: ROBERT BALSOVER                                       Time: 11:25 pm
  18460.   To: STEVE BOOTH (Rcvd)                                    (Read 67 times)
  18461. Subj: R: TC++ SIZE ^SMALL
  18462.  
  18463. Steve,
  18464.      I have TC++ Prof and you're so right, I had to move stuff to another
  18465. partition just to load it.  The bigger the boys, the bigger the toys:-)
  18466. Bob
  18467. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  18468.  
  18469. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AQG3506 Date: 06/21/90
  18470. From: GREGORY WILSON                                        Time: 12:58 pm
  18471.   To: ALL                                                   (Read 70 times)
  18472. Subj: MSC VS TC
  18473.  
  18474. The more I read the msgs in this msg base, the more I begin to wonder if I
  18475. should convert from MSC to TC. Does anyone have any good reasons why I
  18476. should not? Are there any advantages to MSC over TC? Does Borland have a
  18477. better product?
  18478. Thanks!
  18479. Gregory Wilson
  18480. ---------------
  18481. Following thread
  18482.  
  18483. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AQN2976 Date: 06/21/90
  18484. From: GRANT ELLSWORTH (Leader)                              Time: 07:49 pm
  18485.   To: GREGORY WILSON (Rcvd)                                 (Read 67 times)
  18486. Subj: R: MSC VS TC
  18487.  
  18488. There are at least 3 known "advantages" to M$C over TC, and maybe TC++:
  18489.  
  18490. 1.  Many 3rd party firmware (add-on cards) vendors who supply users with
  18491.     software libraries to drive the firmware  only support M$C
  18492. 2.  M$C 6.0 will support os/2 and Windows 3.0 application development
  18493.     as well as development for un-augmented DOS
  18494. 3.  M$C 5.1/6.0 provides full XENIX support and is said to be fully
  18495.     Unix-compatible (source level)
  18496.  
  18497. As to "better" ... one  must ask "better for whom" and "what is it going
  18498. to be used for"  ...
  18499.  
  18500. And if some absolute standard for defining better, the above questions
  18501. notwithstanding, is available, I haven't seen it.
  18502.  
  18503. Grant
  18504. ---------------
  18505. ** Current thread: MSC VS TC
  18506.  
  18507. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AQS1187 Date: 06/21/90
  18508. From: GREGORY WILSON                                        Time: 11:19 pm
  18509.   To: GRANT ELLSWORTH (Rcvd)                                (Read 67 times)
  18510. Subj: R: MSC VS TC
  18511.  
  18512. Good point!
  18513. Thanks!
  18514. Gregory Wilson
  18515. ---------------
  18516. ** Current thread: MSC VS TC
  18517.  
  18518. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3ARG1342 Date: 06/22/90
  18519. From: CHAD GIBBONS                                          Time: 12:22 pm
  18520.   To: GREGORY WILSON (Rcvd)                                 (Read 67 times)
  18521. Subj: R: MSC VS TC
  18522.  
  18523. In addition to having a wider usage base than TC, MSC _does_ generate much
  18524. better code than TC can.  TC was written to compile quickly and often does
  18525. not do a very good job of code optimization.  For example, I took a simple
  18526. routine to calculate some formulas in three languages: Turbo Pascal, Turbo
  18527. C 2.0, and MSC V5.1.  I turned off optimizations in the C languages, and
  18528. something interesting occured.  Turbo Pascal generated better code than
  18529. Turbo C did, while MSC generated much better code than either of the Turbo
  18530. products.
  18531.  
  18532. _Computer Language_ magazine had a C article early last year in which they
  18533. compared most of the C compilers.  Turbo C had most of the good marks, but
  18534. code generation did not compare to MSC.
  18535.  
  18536. Turbo C++ may have changed this, however.
  18537. ---------------
  18538. ** Current thread: MSC VS TC
  18539.  
  18540. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3ARK0948 Date: 06/22/90
  18541. From: GREGORY WILSON                                        Time: 04:15 pm
  18542.   To: CHAD GIBBONS (Rcvd)                                   (Read 71 times)
  18543. Subj: R: MSC VS TC
  18544.  
  18545. Thanks Chad! I had rather wait a few more secs for compilation and get
  18546. better code anyday. I hear the MSC 6.0 is even faster. Tried it yet?
  18547. Gregory Wilson
  18548. ---------------
  18549. ** Current thread: MSC VS TC
  18550.  
  18551. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3ARM0256 Date: 06/22/90
  18552. From: GRANT ELLSWORTH (Leader)                              Time: 06:04 pm
  18553.   To: CHAD GIBBONS (Rcvd)                                   (Read 66 times)
  18554. Subj: R: MSC VS TC
  18555.  
  18556. However, there are times when M$C's so-called optimizations are buggy.  I
  18557. spent days chasing down a bug which turned out to be caused when m$C's
  18558. marvelous optimizations reversed the target and the source in code
  18559. generated for some strcpy() functions.  So, there is one more advantage
  18560. to M$C --- it can help your debugging skills tremendously --- exceeded
  18561. only by debugging mainframe programs from memory dumps.
  18562. ---------------
  18563. ** Current thread: MSC VS TC
  18564.  
  18565. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3ARM0697 Date: 06/22/90
  18566. From: GRANT ELLSWORTH (Leader)                              Time: 06:11 pm
  18567.   To: GREGORY WILSON (Rcvd)                                 (Read 64 times)
  18568. Subj: R: MSC VS TC
  18569.  
  18570. If very highly optimized and __bug_free__ code is your stronger
  18571. preference, I suggest you check out the Watcom 8.0 (286) compiler.
  18572.  
  18573. In "native" mode, it passes parameters in registers.  Also, the 7.0
  18574. release proved a fair bit more efficient than M$C in cpu intensive
  18575. loops involving subroutine calls.
  18576.  
  18577. The best "street price" for WC 8.0 is less than best for M$C 6.0.
  18578. ---------------
  18579. ** Current thread: MSC VS TC
  18580.  
  18581. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3ARM1439 Date: 06/22/90
  18582. From: ROBERT BALSOVER                                       Time: 06:23 pm
  18583.   To: GREGORY WILSON (Rcvd)                                 (Read 65 times)
  18584. Subj: R: MSC VS TC
  18585.  
  18586. Gregory,
  18587.      I takes more than a few more seconds.  If possible, I'd suggest you
  18588. find someone with MSC and compile something yourself.  Try a few minutes,
  18589. but that depends on the size of the source file.
  18590. Bob
  18591. ---------------
  18592. ** Current thread: MSC VS TC
  18593.  
  18594. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3ARP2089 Date: 06/22/90
  18595. From: CRAIG SMITH                                           Time: 08:34 pm
  18596.   To: ROBERT BALSOVER (Rcvd)                                (Read 63 times)
  18597. Subj: R: MSC VS TC
  18598.  
  18599. I have both MSC 6.0 and Borland TC++ Pro (and TC Pro, until recently).
  18600. When I have an option, I will go with TC in a heartbeat.  Yeah, MSC might
  18601. generate more efficient code (though insignificantly so in my judgement),
  18602. but it is at the expense of reliability and ease of use.  I have used both
  18603. compilers for developement of everything from database software to
  18604. vision-based machine control, and I love the TurboC-Turbo Debugger
  18605. combination.  The new TC++ Pro package is so seamlessly integrated that it
  18606. makes Microsoft's "Programmer's Workbench" seem more like a "Programmer's
  18607. Torture Chamber".  To say that MS's environment is slow is truly an
  18608. understatement (even on my 386).
  18609.  
  18610. I will continue to use MSC only to support past projects and when
  18611. necessary for the few libraries that support only it.  But if you don't
  18612. yet have Turbo C (especially the new TC++ Integrated Development
  18613. Environement), then you should get it.
  18614. ---------------
  18615. ** Current thread: MSC VS TC
  18616.  
  18617. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3ASF2700 Date: 06/23/90
  18618. From: GREGORY WILSON                                        Time: 11:45 am
  18619.   To: GRANT ELLSWORTH (Rcvd)                                (Read 65 times)
  18620. Subj: R: MSC VS TC
  18621.  
  18622.  GE> If very highly optimized and __bug_free__ code is your stronger
  18623.  GE> preference, I suggest you check out the Watcom 8.0 (286)
  18624.  GE> compiler.
  18625.  
  18626. What are the libs like? Are they fairly compatible with MSC. Also, I use
  18627. CXL libs a lot. Will they compile under it?
  18628. Thanks for your time!
  18629. Gregory Wilson
  18630. ---------------
  18631. ** Current thread: MSC VS TC
  18632.  
  18633. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3ASF3041 Date: 06/23/90
  18634. From: GREGORY WILSON                                        Time: 11:50 am
  18635.   To: ROBERT BALSOVER (Rcvd)                                (Read 67 times)
  18636. Subj: R: MSC VS TC
  18637.  
  18638.  RB> It (MSC) takes more than a few more seconds (than TC).  If
  18639.  RB>  possible, I'd suggest you find someone with MSC and compile
  18640.  RB>  something yourself.  Try a few minutes, but that depends
  18641.  RB> on the  size of the source file.
  18642.  
  18643. I use MSC now and have compared compile times to TC. I agree that TC is
  18644. faster _UNLESS_ you turn on the incremental compile and link that MSC has.
  18645. With this option MSC proves to be a contender. Of course the code size is
  18646. huge with this option but it is great until you need to do the final
  18647. compile which is best done while out to lunch! :)
  18648.  
  18649. I appreciate your time!
  18650. THanks!
  18651. Gregory Wilson
  18652. ---------------
  18653. ** Current thread: MSC VS TC
  18654.  
  18655. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3ASF3335 Date: 06/23/90
  18656. From: GRANT ELLSWORTH (Leader)                              Time: 11:55 am
  18657.   To: GREGORY WILSON (Rcvd)                                 (Read 65 times)
  18658. Subj: R: MSC VS TC
  18659.  
  18660. Gregory, Watcom claims that the 8.0 286 release can produce object code
  18661. which will link with 3rd party M$C-targetted libraries.  I can say from my
  18662. use of 7.0 that many of the lower-level functions have the same names in
  18663. both WC and M$C standard libraries.  The WC80 bulletin has been uploaded
  18664. to the Mahoney collection as: WATC80PI.ZIP.  The various claims and com-
  18665. patibility issues are discussed there-in.  For your purposes, I suggest
  18666. that you focus on the WATC286 bulletin.  The 386 super-duper package also
  18667. described in that zip in a separate bulletin is a Rolls Royce edition for
  18668. 386-specific applications.  Grant
  18669. ---------------
  18670. ** Current thread: MSC VS TC
  18671.  
  18672. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AUE1186 Date: 06/25/90
  18673. From: CHAD GIBBONS                                          Time: 10:19 am
  18674.   To: GRANT ELLSWORTH (Rcvd)                                (Read 65 times)
  18675. Subj: R: MSC VS TC
  18676.  
  18677. Ohyes, Microsoft's optimizations can be _very_ dangerous.  Generally, if
  18678. you use just standard optimization, you won't have trouble.  There are
  18679. extended optimizations for loop enhancements and the dreaded alias
  18680. optimization.  100% "good" code won't run into these problems, but there
  18681. are times where you _need_ to use aliasing in some circumstances.  It
  18682. makes finding these bugs damn hard and the compiler isn't ANY help.
  18683. ---------------
  18684. ** Current thread: MSC VS TC
  18685.  
  18686. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AUR1608 Date: 06/25/90
  18687. From: ROBERT BALSOVER                                       Time: 10:26 pm
  18688.   To: GREGORY WILSON (Rcvd)                                 (Read 65 times)
  18689. Subj: R: MSC VS TC
  18690.  
  18691. Greg,
  18692.      Have you compared it to Tlink 3.0 with extended or expanded memory
  18693. use.  It *screams*.  (MSC increment compile/link compared to TC times)
  18694. Bob
  18695. ---------------
  18696. ** Current thread: MSC VS TC
  18697.  
  18698. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AVI0277 Date: 06/26/90
  18699. From: GREGORY WILSON                                        Time: 02:04 pm
  18700.   To: ROBERT BALSOVER (Rcvd)                                (Read 66 times)
  18701. Subj: R: MSC VS TC
  18702.  
  18703.  RB>│Have you compared it to Tlink 3.0 with extended or expanded memory
  18704.  RB>│ use.  It *screams*.  (MSC increment compile/link compared
  18705.  RB>│to TC  times)
  18706.  
  18707. No, I have not tried it but I will. THe last version of TC I used was 2.0.
  18708. If they are now using EMS for in-memory compile I would not be suprised to
  18709. see it blow everyone else away.
  18710. Thanks,
  18711. Gregory Wilson
  18712. ---------------
  18713. ** Current thread: MSC VS TC
  18714.  
  18715. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AWR2245 Date: 06/27/90
  18716. From: THOMAS ZERUCHA                                        Time: 10:37 pm
  18717.   To: GREGORY WILSON (Rcvd)                                 (Read 61 times)
  18718. Subj: R: MSC VS TC
  18719.  
  18720. I too would *definately* suggest you look at Watcom - 7.0 is available
  18721. now, and 8.0 is better.  The "PRO" version of 8.0 will have Windows and
  18722. OS/2 compatibility, and 100% MSC library compatability.
  18723.    As a testimonial, I was involved in porting 500 pages of C code for
  18724. image processing which used *everything* in the MSC library and called
  18725. external libraries.  Once we figured out what we were doing (i.e. actually
  18726. read the manuals), it took about 2 days.  Watcom uses (faster) registers
  18727. to pass parameters before going to the stack, but using a "cdecl" will
  18728. make it use MSC standards.  The 7.0 libs are 98% compatible - there are a
  18729. few obscure low level calls (e.g. _msize - size of an allocated block)
  18730. which aren't directly included, but it was easy to add them.
  18731.    The code shrunk by 20% and speed up by at least 50% v.s. MSC 5.1 - and
  18732. we are always going too close to the 640K barrier, so this was very
  18733. welcome.  I ported a 3rd party program easily (I had the source - the only
  18734. trouble was finding a pointer to a function that had to be cdecl'ed).
  18735.    The only complaint I would have is that it is slow since the
  18736. optimization takes a lot of time (and I can't reduce it significantly by
  18737. turning things off).  Also complex code (200 lines with lots of
  18738. structuring and math) can overload the optimizer (so it will be much
  18739. slower and bigger).  It can also overload it to the point a compile will
  18740. fail (about 1000 lines, and after an hour on a turbo 286 AT).  The 386
  18741. versions of 8.0 should fix this though.  (Using VIDRAM or such to get 736K
  18742. space also helps this).
  18743. ---------------
  18744. ** Current thread: MSC VS TC
  18745.  
  18746. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AXD2352 Date: 06/28/90
  18747. From: GREGORY WILSON                                        Time: 09:39 am
  18748.   To: THOMAS ZERUCHA (Rcvd)                                 (Read 61 times)
  18749. Subj: R: MSC VS TC
  18750.  
  18751. Thanks for the information! I would like to see it compared to MSC 6.0 now
  18752. that MS now offers the ability to pass params in the registers (QC2.5
  18753. also). Still, I do like the code size and speed change and compatibility.
  18754. I use CXL libs all the time and cannot live without them!
  18755. What is the going price for 8.0?
  18756. Thanks again,
  18757. Gregory Wilson
  18758. ---------------
  18759. ** Current thread: MSC VS TC
  18760.  
  18761. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AZE3579 Date: 06/30/90
  18762. From: GRANT ELLSWORTH (Leader)                              Time: 10:59 am
  18763.   To: THOMAS ZERUCHA (Rcvd)                                 (Read 59 times)
  18764. Subj: R: MSC VS TC
  18765.  
  18766. THere's another plus with the WC compilers (7.0 and, probably 8.0) ...
  18767. the optimized code will not be buggy.  The M$C compilers' optimizations
  18768. are risky ,,, and can produce subtle, hard-to-find bugs.
  18769. ---------------
  18770. ** Current thread: MSC VS TC
  18771.  
  18772. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AZF0274 Date: 06/30/90
  18773. From: GRANT ELLSWORTH (Leader)                              Time: 11:04 am
  18774.   To: GREGORY WILSON (Rcvd)                                 (Read 57 times)
  18775. Subj: R: MSC VS TC
  18776.  
  18777. WC8.0 mail order prices are consistently less the M$C 6.0 from the same
  18778. vendor.  Going prices are around $350 (some less, some more).  Difference
  18779. between MS and WC prices are around $50.
  18780. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  18781.  
  18782. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3ARS0338 Date: 06/22/90
  18783. From: RAY TWEEDALE                                          Time: 11:05 pm
  18784.   To: ALL                                                   (Read 63 times)
  18785. Subj: READ IN CSV
  18786.  
  18787. Anyone here have a function, trick, method, etc. , to read in CSV
  18788. delimited files to a structure?  Would like it to be compatible with MSC
  18789. 6.0 and/or QC 2.0.
  18790.  
  18791. Thanks for all replies.
  18792.  
  18793. ray
  18794. ---------------
  18795.  
  18796. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3ASF3254 Date: 06/23/90
  18797. From: GREGORY WILSON                                        Time: 11:54 am
  18798.   To: ALL                                                   (Read 67 times)
  18799. Subj: CORRUPTED ENV
  18800.  
  18801. Help!
  18802. Is there a way to determine if a program has altered RAM at all.
  18803. I sometime let pointers go astray and later the system will lock
  18804. up. Is there a good way to compare the environments before and
  18805. after to make sure everything was cleaned properly?
  18806.  
  18807. Thanks
  18808. Gregory Wilson
  18809. SYSOP: The Ltd. BBS 708-213-1304
  18810. P.S. Of course it would help if I was more careful!
  18811. ---------------
  18812. Following thread
  18813.  
  18814. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3ASG0171 Date: 06/23/90
  18815. From: GRANT ELLSWORTH (Leader)                              Time: 12:02 pm
  18816.   To: GREGORY WILSON (Rcvd)                                 (Read 66 times)
  18817. Subj: R: CORRUPTED ENV
  18818.  
  18819. I haven't seen anything which will do an environmental checkout.  But,
  18820. there's a Zip in the Mahoney collection called MSCHEAP.ZIP which provides
  18821. some code and routines for detecting corruption in the MSC5.1 heap during
  18822. program execution.  Otherwise, enabling stack checking in the compile
  18823. will provide some protection from heap/stack collision in some memory
  18824. models.  There also may be some programming and data structuring
  18825. techniques which will reduce the probability of misbehaving pointers.
  18826. ---------------
  18827. ** Current thread: CORRUPTED ENV
  18828.  
  18829. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3ATE2369 Date: 06/24/90
  18830. From: GREGORY WILSON                                        Time: 10:39 am
  18831.   To: GRANT ELLSWORTH (Rcvd)                                (Read 66 times)
  18832. Subj: R: CORRUPTED ENV
  18833.  
  18834.  GE> There also may be some programming and data structuring
  18835.  GE> techniques which will reduce the probability of misbehaving
  18836.  GE>  pointers.
  18837.  
  18838. Yeah, I agree. What happened to me is that I was using Mike
  18839. Smedleys SETONKEY and CHGONKEY commands which set up a link list
  18840. in memory of defined "onkey" routines. In one of my functions, I
  18841. was accidentely resetting the keys over and over instead of
  18842. clearing them then resetting them. I go no pointer errors or
  18843. anything for a while. About 3 days later I was doing some heavy
  18844. duty testing and noticed that after a strange combination of
  18845. functions, the windows started "loosing their shadows!". I did
  18846. not know where to start! I started debugging and could not get
  18847. any runtime errors to occur. After playing some more, I found
  18848. that if I tried to repeat the scenario more than 3 times, the
  18849. screen would scramble and the entire system would lock up.
  18850. Finnaly I stumbled on the problem. At the same time, I had
  18851. noticed my system locking up after using the program while in
  18852. other applications. After finding the problem I did a complete
  18853. print of all 3000 lines of code and started going through the
  18854. code line by line. It would have been nice to have a tool to
  18855. detect that DOS was getting corrupted.
  18856.  
  18857. Anyway..thanks for your help! This is by far the best 'C' message
  18858. base on any BBS. No crap...just good conversation.
  18859.  
  18860. Gregory Wilson
  18861.  
  18862.  
  18863.  
  18864. By the way, I am now bald. Unlike other languages, C makes you pay for its
  18865. incredible speed and portability!
  18866. ---------------
  18867. ** Current thread: CORRUPTED ENV
  18868.  
  18869. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AU21588 Date: 06/25/90
  18870. From: PAUL MCKENZIE                                         Time: 02:26 am
  18871.   To: GREGORY WILSON (Rcvd)                                 (Read 67 times)
  18872. Subj: R: CORRUPTED ENV
  18873.  
  18874. You can try BOUNDS CHECKER from NU-MEGA Technologies.  This software
  18875. checks Programs written in Turbo or MSC for run away pointers and invalid
  18876. accesses to uninitialized memory.  Price is about $250.00.
  18877. I have tried it, and it has saved me a lot of debugging time.
  18878.                                        Paul McKenzie
  18879. ---------------
  18880. ** Current thread: CORRUPTED ENV
  18881.  
  18882. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AVC3252 Date: 06/26/90
  18883. From: GREGORY WILSON                                        Time: 08:54 am
  18884.   To: PAUL MCKENZIE (Rcvd)                                  (Read 65 times)
  18885. Subj: R: CORRUPTED ENV
  18886.  
  18887. Tooo expensive for me. Do you know of any cheaper programs.
  18888. Gregory Wilson
  18889. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  18890.  
  18891. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AV12323 Date: 06/26/90
  18892. From: SEBASTIAN DEBROGLIE                                   Time: 01:38 am
  18893.   To: ALL                                                   (Read 67 times)
  18894. Subj: MSC DIFFICULTIES??
  18895.  
  18896. I have seen loads of messages talking about diffulcities using MSC
  18897. as well as their reliability.  I use QC 2.00--do these comments apply to
  18898. this compiler as well?  Is there a list of common problems with MSC
  18899. compilers??  You have me a bit unsettled about all of this.
  18900.      Thanks for any responses in advance.
  18901.      --Sebastian
  18902. ---------------
  18903. Following thread
  18904.  
  18905. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AVI0508 Date: 06/26/90
  18906. From: GREGORY WILSON                                        Time: 02:08 pm
  18907.   To: SEBASTIAN DEBROGLIE (Rcvd)                            (Read 67 times)
  18908. Subj: R: MSC DIFFICULTIES??
  18909.  
  18910.  SD>│I have seen loads of messages talking about diffulcities using
  18911.  SD>│MSC as well as their reliability.  I use QC 2.00--do these
  18912.  SD>│comments apply to this compiler as well?  Is there a list
  18913.  SD>│of common problems with MSC compilers??  You have me a bit
  18914.  SD>│unsettled about all of this.
  18915.  
  18916. The list for TC is just as long on other BBS's. It seems to depend on who
  18917. you are talking to. I am interested to see what MSC 6.0 does. Hopefully a
  18918. book will not have to be published called "The Bugs of MSC 6.0".
  18919.  
  18920. I use Quick C 2.5 and have had no problems except with the debugger. The
  18921. debugger does not recognize variables sometimes depending on where you
  18922. declare them. I left a note on CSERVE and sure enough they came back and
  18923. said I found a bug. Well, there's another free update for me!
  18924.  
  18925. Gregory Wilson
  18926. ---------------
  18927. ** Current thread: MSC DIFFICULTIES??
  18928.  
  18929. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AVQ3123 Date: 06/26/90
  18930. From: SEBASTIAN DEBROGLIE                                   Time: 09:52 pm
  18931.   To: GREGORY WILSON (Rcvd)                                 (Read 64 times)
  18932. Subj: R: MSC DIFFICULTIES??
  18933.  
  18934. Thanx for the reply.
  18935. Is it worth the upgrade to QC2.5??  I received the update information,
  18936. but I don't see any clear advantages.  Am I missing something??
  18937. Also, I have a knotty (at least it seems that way to me) problem in a
  18938. program.  For some reason I can't get scanf() to read floating point
  18939. numbers correctly.  Integers are fine, but floating point numbers suddenly
  18940. become either 0.000 or 1.#INF00.  I have no idea why.  I even ran one of
  18941. the sample programs from the QC advisor help area and I got the same
  18942. results!!  I am a new C programmer & hope this is not a stupid question,
  18943. but I have spent over 10hrs. trying to work it out.  If you have ever had
  18944. this problem, I would be extraordinarily grateful for any comments.
  18945.      So, you get a free update if you find a bug??  That's kinda nice!
  18946. ---------------
  18947. ** Current thread: MSC DIFFICULTIES??
  18948.  
  18949. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AVR0024 Date: 06/26/90
  18950. From: ROBERT BALSOVER                                       Time: 10:00 pm
  18951.   To: SEBASTIAN DEBROGLIE (Rcvd)                            (Read 62 times)
  18952. Subj: R: MSC DIFFICULTIES??
  18953.  
  18954. Sebastian,
  18955.      Those comments only apply to MSC when you play with the
  18956. optimizations.
  18957. Bob
  18958. ---------------
  18959. ** Current thread: MSC DIFFICULTIES??
  18960.  
  18961. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AVR0283 Date: 06/26/90
  18962. From: ROBERT BALSOVER                                       Time: 10:04 pm
  18963.   To: GREGORY WILSON (Rcvd)                                 (Read 64 times)
  18964. Subj: R: MSC DIFFICULTIES??
  18965.  
  18966. Gregory,
  18967.      Since I use TC I would apprieciate it if you could post those bugs
  18968. here for me.  Don't misunderstand me, this is not a challenge.  If there
  18969. are unfixed bugs in TC that haven't had patches made by Borland I need to
  18970. know about them.
  18971. Bob
  18972. ---------------
  18973. ** Current thread: MSC DIFFICULTIES??
  18974.  
  18975. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AWD1634 Date: 06/27/90
  18976. From: GREGORY WILSON                                        Time: 09:27 am
  18977.   To: SEBASTIAN DEBROGLIE (Rcvd)                            (Read 65 times)
  18978. Subj: R: MSC DIFFICULTIES??
  18979.  
  18980.  SD>│Is it worth the upgrade to QC2.5??
  18981.  
  18982. I think so. I went ahead and upgraded to QC/QuickAsm. The biggest
  18983. advantage is the debugger. They added a few features. Also, the editor
  18984. has many more options such as custom colors, tab handling (spaces or true
  18985. tabs),..etc.. Also, I like the ability to create COM files for small utils
  18986. and such. I can't really tell a difference when it comes to speed but the
  18987. upgrade is still worth the price.
  18988.  
  18989.  SD>│For some reason I can't get scanf() to read floating point numbers
  18990.  SD>│ correctly.  Integers are fine, but floating point numbers
  18991.  SD>│suddenly  become either 0.000 or 1.#INF00.
  18992.  
  18993. Not sure what to tell you on this one. Maybe you could "dump" your source
  18994. in a msg and let me look at it. Microsoft has a forum on CompuServe for
  18995. the tracking of bugs...I wil take a look and let you know.
  18996.  
  18997. Anyway...talk to you later,
  18998. Gregory Wilson
  18999. P.S. If you do not mind a long distance call, call my BBS 708-213-1304. I
  19000. have quite a lot of 'C' related stuff.
  19001. ---------------
  19002. ** Current thread: MSC DIFFICULTIES??
  19003.  
  19004. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AWD1748 Date: 06/27/90
  19005. From: GREGORY WILSON                                        Time: 09:29 am
  19006.   To: ROBERT BALSOVER (Rcvd)                                (Read 63 times)
  19007. Subj: R: MSC DIFFICULTIES??
  19008.  
  19009. I think that Borland has sent patches for the ones I was talking about. I
  19010. saw a list on CSERVE and will try to find it. One advantage of Borland
  19011. over MS is there willingness to put out patches where MS makes you wait
  19012. until the next release unless it is severe.
  19013. Oh well...
  19014. Gregory Wilson
  19015. ---------------
  19016. ** Current thread: MSC DIFFICULTIES??
  19017.  
  19018. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AWE0376 Date: 06/27/90
  19019. From: ROBERT BALSOVER                                       Time: 10:06 am
  19020.   To: GREGORY WILSON (Rcvd)                                 (Read 61 times)
  19021. Subj: R: MSC DIFFICULTIES??
  19022.  
  19023. Gregory,
  19024.      No need to look for that list of TC patches, I got them when they
  19025. came out.  I was just trying to find unknown bugs.
  19026. Bob
  19027. ---------------
  19028. ** Current thread: MSC DIFFICULTIES??
  19029.  
  19030. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AWE1985 Date: 06/27/90
  19031. From: GRANT ELLSWORTH (Leader)                              Time: 10:33 am
  19032.   To: GREGORY WILSON (Rcvd)                                 (Read 62 times)
  19033. Subj: R: MSC DIFFICULTIES??
  19034.  
  19035. Maybe it's perspective and/or exposure.... While I've had aa few problems
  19036. with TC2.0, the bugs I've found in M$C5.1 are "scarier".  And, while I've
  19037. seen bugs/problems reported here and on other bbs's on TC and now, TC++,
  19038. the gravity and number of problems I've seen reported on M$C6.0 seem
  19039. greater and more pervasive.
  19040.  
  19041. On the other hand, the complaint level I've seen on QC2.5 has been
  19042. relatively low.
  19043. ---------------
  19044. ** Current thread: MSC DIFFICULTIES??
  19045.  
  19046. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3B1S2946 Date: 07/01/90
  19047. From: SEBASTIAN DEBROGLIE                                   Time: 11:49 pm
  19048.   To: GREGORY WILSON (Rcvd)                                 (Read 49 times)
  19049. Subj: R: MSC DIFFICULTIES??
  19050.  
  19051. Hey, thanks much for your prompt help!!!  I really appreciate it--I don't
  19052. really know where else to go for help.  I'll try to dump the relevent code
  19053. into a message for you to take a look at.
  19054.                     Thanks!!!
  19055.                     --Sebastian
  19056. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  19057.  
  19058. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AVI0099 Date: 06/26/90
  19059. From: GREGORY WILSON                                        Time: 02:01 pm
  19060.   To: ALL                                                   (Read 64 times)
  19061. Subj: MEMORY MAP ?
  19062.  
  19063. To save me several hours work, does anyone have a function that will
  19064. either display or create a char array of a list of all TSR's in memory?
  19065. I need something similiar to MAPMEM that I can search and report from.
  19066. Thanks,
  19067. Gregory Wilson
  19068. P.S. MSC 5.1/QC 2.5 compatible
  19069. ---------------
  19070.  
  19071. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AWG1571 Date: 06/27/90
  19072. From: STEVE BOOTH                                           Time: 12:26 pm
  19073.   To: ALL                                                   (Read 65 times)
  19074. Subj: C QUESTION/PROBLEM
  19075.  
  19076. /* Hello All "C" experts!
  19077.  
  19078.    I'm having a weird problem with some "C" code I wrote. Could
  19079. someone please tell me what I'm doing wrong?? I'm receiving a
  19080. compilation error using the TC++ compiler. The exact text of the
  19081. error is: Type mismatch in redeclaration of 'strnbrb'.  The problem
  19082. seems to have something to do with the "float" type  in the line
  19083. entitled "This Line!". If I change the type to a "long", it compiles
  19084. correctly!  Anyone have any ideas?  THANKS!!*/
  19085.  
  19086. #include <conio.h>
  19087. #include <string.h>
  19088. #include <stdio.h>
  19089. void main(void)
  19090. {
  19091. char line1[151];
  19092. int retval;
  19093. float nbr=1234.56;
  19094. line1[0]='\0';
  19095. retval = strnbrb(line1, nbr, 20, "$T5.5");
  19096. if (!retval) printf("%s\n",line1);
  19097. }
  19098. int strnbrb(char *str1, float nbr,int pos,char *form) /* This Line!*/
  19099. {
  19100.  printf("%s%5.5f%d%S",str1,nbr,pos,form);
  19101.  return(0);
  19102. }
  19103. ---------------
  19104. Following thread
  19105.  
  19106. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AWJ0511 Date: 06/27/90
  19107. From: STEVE BOOTH                                           Time: 03:08 pm
  19108.   To: STEVE BOOTH (Rcvd)                                    (Read 64 times)
  19109. Subj: R: C QUESTION/PROBLEM
  19110.  
  19111. Additional information:
  19112.     I tried this code on Turbo C Version 2.0.  It compiled cleanly.
  19113. I contacted Borland and discussed the situation with them.  He
  19114. wasn't able to get that error, but got a different one.  Said that
  19115. the problem could be got around by specifying a prototype. I needed
  19116. to type: int strnbrb(char *, float, int, char *); after the #define
  19117. statements.  It's interesting to me that SOMETIMES this isn't
  19118. required, sometimes it is.  I must admit however, it is good/clean
  19119. coding practice to have the prototype.
  19120. ---------------
  19121. ** Current thread: C QUESTION/PROBLEM
  19122.  
  19123. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AWN1874 Date: 06/27/90
  19124. From: GRANT ELLSWORTH (Leader)                              Time: 07:31 pm
  19125.   To: STEVE BOOTH (Rcvd)                                    (Read 64 times)
  19126. Subj: R: C QUESTION/PROBLEM
  19127.  
  19128. As I understand it, the ANSI_compliant C compiler within TC++ is a lot
  19129. more stringent about requiring functions to have prototypes declared.
  19130. According to the ANSI standard, as I read it in K+R 2nd Edition, your
  19131. functions MUST have prototypes declared ---rather than depending on
  19132. implied prototypes from first usage (dangerous anyway).
  19133. ---------------
  19134. ** Current thread: C QUESTION/PROBLEM
  19135.  
  19136. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AWQ3428 Date: 06/27/90
  19137. From: STEVE BOOTH                                           Time: 09:57 pm
  19138.   To: GRANT ELLSWORTH (Rcvd)                                (Read 61 times)
  19139. Subj: R: C QUESTION/PROBLEM
  19140.  
  19141. Yeah, I have to agree with you... I find it "interesting" that TC++
  19142. isn't consistant throughout.  I declared some other functions
  19143. the same way (only didn't use the FLOAT data type) and they worked.
  19144. I decided that for my own piece of mind to go back to those
  19145. functions and prototype them as well. The way my luck was been going
  19146. I'd get nailed just as soon as I depended on them to be one way.
  19147. That error message stunk, tho (IMHO)... I'm not an expert "C"er by
  19148. ANY stretch of the imagination... I'm mired in Control Data systems
  19149. and work in FORTRAN and CDC Assembly Language. Oh well... thanks for
  19150. the speedy and noncondescending response.  I really appreciate it.
  19151. Best Regards,
  19152.      Steve...
  19153. ---------------
  19154. ** Current thread: C QUESTION/PROBLEM
  19155.  
  19156. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AZE3398 Date: 06/30/90
  19157. From: GRANT ELLSWORTH (Leader)                              Time: 10:56 am
  19158.   To: STEVE BOOTH (Rcvd)                                    (Read 60 times)
  19159. Subj: R: C QUESTION/PROBLEM
  19160.  
  19161. In working with TC++ as an ANSI compliant C compiler, look out for other
  19162. glitches and be extremely wary of those docs where Borland notes what
  19163. they implemented for the "undefined behavior" and "ambiguous" standards.
  19164. For example: in one program I recently converted, divide by 0 yeilded
  19165. 0 ---- not a divide error, as I would have expected.  My program was
  19166. not properly coded to protect against 0 value variables (BUG).  There
  19167. are other little deviations from TC2.0 behavior, but I haven't stumbled
  19168. into them yet.  I have an uneasy feeling right now that this new compiler
  19169. has some very ugly problems lurking there-in and I'm concerned that I
  19170. might be looking at a toss-up between M$C 6.0 and TC++ 1.0 for lack of
  19171. reliability (OUCH).  It's just a question of where I'm going to get bit.
  19172. I have yet to evaluate WC8.0 (286) as a real alternative for the non-
  19173. super-optimized programs/applications.  Grant
  19174. ---------------
  19175. ** Current thread: C QUESTION/PROBLEM
  19176.  
  19177. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3B1H3001 Date: 07/01/90
  19178. From: ROBERT BALSOVER                                       Time: 01:50 pm
  19179.   To: GRANT ELLSWORTH (Rcvd)                                (Read 53 times)
  19180. Subj: R: C QUESTION/PROBLEM
  19181.  
  19182. Grant,
  19183.      Do you know of any bug lists for TC++?  The only problems I know of
  19184. are:
  19185. 1.     I have some problems placing a library into a overlay, I have the
  19186. source and did compile with the -Y option.
  19187. 2.     The bcd package doesn't always produce the rusults expected.
  19188. .
  19189.      The first one is probably more Tlink than TC++ and the second one is
  19190. just the method they choose to impliment bcd, not really a 'compiler' bug.
  19191. .
  19192.      Borland has always been good about posting patches, but I don't want
  19193. to find out I have a lurker because I see it listed in the patches.  I'd
  19194. like to avoid them now.
  19195. Thanks
  19196. Bob
  19197. ---------------
  19198. ** Current thread: C QUESTION/PROBLEM
  19199.  
  19200. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3B1K0607 Date: 07/01/90
  19201. From: GRANT ELLSWORTH (Leader)                              Time: 04:10 pm
  19202.   To: ROBERT BALSOVER (Rcvd)                                (Read 52 times)
  19203. Subj: R: C QUESTION/PROBLEM
  19204.  
  19205. Bob, BI hasn't posted any patches/fixes for TC++, yet.  And I have not
  19206. seen a usable "known bug" list.  Many of the problems I have read about
  19207. on CI$ seem to arise from "obscure" usage or from pushing the product
  19208. to some extremes.  Then there are those problems arising from more
  19209. stringent enforcement of the ANSI standard.
  19210.  
  19211. The other area for concern seems to be in the optimization (and lack
  19212. there-of) for speed and size.  While ALL my benchmark tests show TC++
  19213. as being marginally better than TC2.0, the .exe's can be significantly
  19214. larger.
  19215.  
  19216. There is at least one report of TC++ generating M$lopC-style unreliable
  19217. code.  I haven't seen it in any of my current test conversions, but that
  19218. doesn't mean the problems are not there.  After spending many days chasing
  19219. what turned out to be several cases of M$lop code generation earlier this
  19220. year, I'm going to approach using TC++ with extreme caution until we know
  19221. whether the problem reports are mis-usage flukes.
  19222.  
  19223. Other than anxiety about breaking things that worked in TC2.0, I'm more
  19224. than a little irritated that PRJ2MAK and TCCNVT didn't make it onto the
  19225. release diskettes === especially TCCNVT.  I detest hand-cobbling
  19226. turboc.cfg files from memory of what I had in the IDE.
  19227.  
  19228. Grant
  19229. ---------------
  19230. ** Current thread: C QUESTION/PROBLEM
  19231.  
  19232. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3B1R3342 Date: 07/01/90
  19233. From: ROBERT BALSOVER                                       Time: 10:55 pm
  19234.   To: GRANT ELLSWORTH (Rcvd)                                (Read 52 times)
  19235. Subj: R: C QUESTION/PROBLEM
  19236.  
  19237. Grant,
  19238.      One thing I found a little irritating about the TC++ IDE was it tries
  19239. to load any .prj it finds in the current directory.  These include the
  19240. older TC 2.0 .prj files and others that have nothing to do with a Borland
  19241. Compiler.  I hate getting a stupid error message when I start the IDE
  19242. because it can't read the .prj file in the directory, it should load it
  19243. only if I ask for it.  I know its a little thing but it could have been
  19244. avoided by a little thinking a head on their part.
  19245.      I found some interesting looking C++ code on the UNIX forem (CIS),
  19246. but its a little dated and doesn't compile cleanly, have you found any PD
  19247. C++ code to look at?  I'm tring to get the feel of C++, but there isn't
  19248. alot of material visible to me.
  19249. Bob
  19250. ---------------
  19251. ** Current thread: C QUESTION/PROBLEM
  19252.  
  19253. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3B2M2621 Date: 07/02/90
  19254. From: GRANT ELLSWORTH (Leader)                              Time: 06:43 pm
  19255.   To: ROBERT BALSOVER (Rcvd)                                (Read 50 times)
  19256. Subj: R: C QUESTION/PROBLEM
  19257.  
  19258. Bob, I haven't seen anything but the few snippets you probably have.
  19259. I wonder whether C++ in any form has been around long enough for much
  19260. source code to have accumulated.  If YOU locate any good collections,
  19261. pass it on!  Grant
  19262. ---------------
  19263. ** Current thread: C QUESTION/PROBLEM
  19264.  
  19265. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3BBQ2806 Date: 07/07/90
  19266. From: STEVE BOOTH                                           Time: 09:46 pm
  19267.   To: GRANT ELLSWORTH (Rcvd)                                (Read 38 times)
  19268. Subj: R: C QUESTION/PROBLEM
  19269.  
  19270. Message CC'd to:
  19271.      GRANT ELLSWORTH
  19272.      ROBERT BALSOVER
  19273.  
  19274. Grant, I also find it interesting that BI is now documenting
  19275.        some other "features" of some of the library functions.
  19276.        Specifically, the "fseek" library function on page 174
  19277.        contains a cute little arrow stating that you can't
  19278.        depend upon receiving a zero value to indicate successful
  19279.        completion of the function! e.g., all bets are off baby, cuz
  19280.        DOS mucks around in this area... Sounds like somebody
  19281.        complained regarding this one!  Not a bug, just a feature!
  19282.        Steve...
  19283. ---------------
  19284. ** Current thread: C QUESTION/PROBLEM
  19285.  
  19286. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3BC21541 Date: 07/08/90
  19287. From: ROBERT BALSOVER                                       Time: 02:25 am
  19288.   To: STEVE BOOTH (Rcvd)                                    (Read 38 times)
  19289. Subj: R: C QUESTION/PROBLEM
  19290.  
  19291. Steve,
  19292.      If DOS is undependable in returning a error code for int 21h function
  19293. 42h, you can't blame BI for this one.   The 'feature' belongs to MS.
  19294. Bob
  19295. ---------------
  19296. ** Current thread: C QUESTION/PROBLEM
  19297.  
  19298. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3BDA1985 Date: 07/09/90
  19299. From: STEVE BOOTH                                           Time: 06:33 am
  19300.   To: ROBERT BALSOVER (Rcvd)                                (Read 34 times)
  19301. Subj: R: C QUESTION/PROBLEM
  19302.  
  19303. Bob,
  19304.     Yep, you're right.  Somebody must have called BI on it, tho.
  19305. Doesn't seem the type of thing that would be inserted a manual as
  19306. an "incidently".  Have fun "C"ing...
  19307.  
  19308. Steve...
  19309. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  19310.  
  19311. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AWI3126 Date: 06/27/90
  19312. From: MICHAEL MCCLUNE                                       Time: 02:52 pm
  19313.   To: ALL                                                   (Read 62 times)
  19314. Subj: ITS BROKEN?
  19315.  
  19316. All Who use QC2.5 and those who like good ones
  19317. QC2.5 is broken! Thats what a tech at M$ said to me when I asked
  19318. why the quickwatch wouldn't recognize a struct I had defined.
  19319. The incremental link still has some problems so if your debugging turn off
  19320. the ilink. Ilink was broke in QC2.0 and it's still broke. If anyone
  19321. else has found something broke in QC please post it here.
  19322. Mike
  19323. ---------------
  19324. Following thread
  19325.  
  19326. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AXD2037 Date: 06/28/90
  19327. From: GREGORY WILSON                                        Time: 09:33 am
  19328.   To: MICHAEL MCCLUNE (Rcvd)                                (Read 62 times)
  19329. Subj: R: ITS BROKEN?
  19330.  
  19331. I have not had a problem with QUICKWATCH yet but I did discover a bug when
  19332. trying to watch variables declared to be extern. For example:
  19333.  
  19334. PROGRAM 1       #include<stdio.h>
  19335.                 extern int var1;
  19336.  
  19337.                 main()
  19338.                 {
  19339.                     ..........
  19340.                 }
  19341.  
  19342. PROGRAM 2       #include<stdio.h>
  19343.                 int var1;
  19344.  
  19345.                 function(....)
  19346.                 {
  19347.                    ......
  19348.                 }
  19349.  
  19350. If I tried to watch a variable in PROGRAM 2, the debugger would say
  19351. that "var1 is undefined". Being still somewhat a beginner at 'C' I
  19352. thought it was something I was doing wrong so I spent hours trying
  19353. to fix it. I finnaly left a msg on CSERVE to the MS people and they
  19354. said it was a bug. I was the first to find it.
  19355.  
  19356. Oh well...I still like it and still feel it is worth the update. I
  19357. just wish that MS would issue patches to fix these aggravating bugs!
  19358.  
  19359. Gregory Wilson
  19360. ---------------
  19361. ** Current thread: ITS BROKEN?
  19362.  
  19363. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AZE3264 Date: 06/30/90
  19364. From: MICHAEL MCCLUNE                                       Time: 10:54 am
  19365.   To: GREGORY WILSON (Rcvd)                                 (Read 59 times)
  19366. Subj: R: ITS BROKEN?
  19367.  
  19368. Greg,
  19369. A variable must be defined in one file as
  19370. int i=0;
  19371. fun_bod{
  19372.      bod
  19373.      .
  19374.      .
  19375. }
  19376. then decalred as externally defined in the other mod
  19377. extern int i;
  19378. fun_bod_2{
  19379.      bod
  19380.      .
  19381.      .
  19382. }
  19383. Give that a shot once. Of course in the first file you could declare
  19384. var i explicitly extern which may be a better choice, other wise the
  19385. compiler condsiders it as implicit.
  19386. As far as my message goes do you have the incremental link turned on?
  19387. This is when the MS techie told me "it's broken in that respect"
  19388. Give the above code a try once and let me know.
  19389. Mike
  19390. ---------------
  19391. ** Current thread: ITS BROKEN?
  19392.  
  19393. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AZN0422 Date: 06/30/90
  19394. From: GREGORY WILSON                                        Time: 07:07 pm
  19395.   To: MICHAEL MCCLUNE (Rcvd)                                (Read 55 times)
  19396. Subj: R: ITS BROKEN?
  19397.  
  19398. Yeah...I had it extern in one and just regular declaration in the other
  19399. file and also had ILINK on. I will try without ILINK and compare.
  19400. Thanks again!
  19401. When are they going to fix this problem?????!!!!????
  19402. Gregory Wilson
  19403. ---------------
  19404. ** Current thread: ITS BROKEN?
  19405.  
  19406. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3B1M1913 Date: 07/01/90
  19407. From: MICHAEL MCCLUNE                                       Time: 06:31 pm
  19408.   To: GREGORY WILSON (Rcvd)                                 (Read 51 times)
  19409. Subj: R: ITS BROKEN?
  19410.  
  19411. Greg,
  19412. Who knows, its been broke for some time now!
  19413. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  19414.  
  19415. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AZD0382 Date: 06/30/90
  19416. From: ANDY HUBBELL                                          Time: 09:06 am
  19417.   To: ALL                                                   (Read 62 times)
  19418. Subj: INCREMENTING POINTERS - PROBLEM
  19419.  
  19420. I have a question concerning the incrementing of pointers.  I read through
  19421. my books and have not had any success.  I uploaded the file called
  19422. ANDY'S.ZIP into the Conversations area and it contains more information on
  19423. my problem in a read.me file.  It also contains sample code that contains
  19424. an example leading up to the problem area.
  19425.  
  19426. I am not an expert in 'C', but I do know that pointers can be incremented.
  19427. My problem is slightly different.  In an attempt to conserve memory I
  19428. decided to pass a pointer to a structure of arrays containing three pieces
  19429. of data, and the number of arrays within a function call.  There are other
  19430. items in the function call as well, but they aren't important right now.
  19431. I can access the first item in  the first array in the structure of
  19432. arrays, but I can't even get to the second item in the first array.  What
  19433. I need to do is get to all items in all arrays.
  19434.  
  19435. If you have some free time, which I now everybody lacks, and you would
  19436. like to help me out of a jam.  I would really appreciate it.  Come on and
  19437. show off you knowledge.
  19438.  
  19439. thanks,      andy
  19440. ---------------
  19441.  
  19442. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AZH0937 Date: 06/30/90
  19443. From: JOHN ABATTE                                           Time: 01:15 pm
  19444.   To: ALL                                                   (Read 60 times)
  19445. Subj: FILE READS IN C
  19446.  
  19447.     I'm trying to read in a text file to convert it to a delimited ascii
  19448. file so that it can be imported by dBase III. Initially I wrote the
  19449. routine to read in one line at a time using fgets, but this is rather
  19450. slow. I would like to read the entire file all at once to try to speed
  19451. up the program, but I'm running into a couple of rather nasty glitches.
  19452.  
  19453.     First off, I get a compiler warning "Conversion may lose significant
  19454. digits" on the call to fread. After the call to fread, the "count"
  19455. variable is less than the file size ( fb.ff_fsize ) so the program
  19456. inevitably aborts. I'm compiling it with the COMPACT memory model to
  19457. ensure a large enough heap to read the file (approx 130K) so this
  19458. shouldn't be the culprit. I've even tried the cast on fb.ff_fsize since
  19459. it's defined as type long, and fread wants an int, but this didn't make
  19460. any difference. BTW the compiler is TC++.
  19461.  
  19462.     If anyone has any ideas about how to read the file in one big gulp
  19463. I'd sure like to know.
  19464.  
  19465. int process_file(char *infile, char *outfile)
  19466. {
  19467.   FILE *in, *out;  /* pointers to input & output files */
  19468.   char far *inbuf;  /* far pointer to input buffer */
  19469.   char outbuf[BUFFSIZE]; /* output buffer */
  19470.   struct ffblk fb;  /* structure to hold file size, defined in dir.h */
  19471.   unsigned long count; /* number of items read */
  19472.  
  19473.   findfirst(infile, &fb, 0); /* get info about the file */
  19474.                              /* allocate the buffer for the fread */
  19475.   inbuf = farcalloc(fb.ff_fsize, sizeof(char));
  19476.   in = fopen(infile, "rt");
  19477.   out = fopen(outfile, "wt");
  19478.   count = fread(inbuf, sizeof(char), (long)fb.ff_fsize, in);
  19479.   if (count < fb.ff_fsize)                                ^
  19480.     exit(1);                                              |
  19481.   ...                                                     |
  19482.         Compiler issues the warning at this point ---------
  19483.  
  19484. }
  19485.  
  19486. Thanks in advance...John.
  19487.  
  19488. ---------------
  19489. Following thread
  19490.  
  19491. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3BAD0376 Date: 07/06/90
  19492. From: VICTOR DURA                                           Time: 09:06 am
  19493.   To: JOHN ABATTE (Rcvd)                                    (Read 47 times)
  19494. Subj: R: FILE READS IN C
  19495.  
  19496. John,
  19497. Sorry I can't help with a suggestion on how to read the file in C, but
  19498. there are a couple of programs in the mahoney collection that will convert
  19499. a text file to a comma seperated - quote delimited file for appending into
  19500. db3. Two that I know of are PC-COMMA.ZIP and QAD.ZIP.
  19501. ...Vic Dura
  19502. ---------------
  19503. ** Current thread: FILE READS IN C
  19504.  
  19505. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3BDA1908 Date: 07/09/90
  19506. From: JOHN ABATTE                                           Time: 06:31 am
  19507.   To: VICTOR DURA (Rcvd)                                    (Read 36 times)
  19508. Subj: R: FILE READS IN C
  19509.  
  19510. Thanks anyway Victor. I finally gave up on trying to read the entire file
  19511. at once, and settled on reading it a line at a time. I had completed it
  19512. prior to leaving the message, but I was attempting to convert it to see if
  19513. it would speed up the operation.
  19514.  
  19515. John.
  19516. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  19517.  
  19518. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3AZJ3396 Date: 06/30/90
  19519. From: DAVID SAMPSON                                         Time: 03:56 pm
  19520.   To: ALL                                                   (Read 58 times)
  19521. Subj: WINDOWS SDK PROGRAMMING HELP
  19522.  
  19523.  
  19524. I'm having difficulty using the Anisotropic mapping mode in the
  19525. Windows SDK.  To learn how to use this mode, I'm trying to map a
  19526. logical coordinate system that has an X, Y axis extent from zero to
  19527. 10, to the viewport.  The viewport extent is based on detecting the
  19528. client window coordinates.
  19529.  
  19530. I then shift the viewport origin from the upper left hand corner of
  19531. the window to the lower left corner so that the mappings to the window
  19532. from logical coordinates will look like the 1st quadrant of a
  19533. cartesian coordinate system.  Then I want to draw a rectangle with a
  19534. black pen and fill it with a gray brush.
  19535.  
  19536. I've been able to use that default mapping mode (MM_TEXT) with no
  19537. trouble.  But when I use the code below, I don't see anything on the
  19538. display.  I've played around with the extents and plotting points, but
  19539. had no luck.  I'm wondering if I've set the viewport up so that I'm
  19540. not really accomplishing what I want (i.e. I'm not looking at what I'm
  19541. drawing, or I'm not filling the viewport/client area with the 1st
  19542. quadrant of the logical coordinate system).
  19543.  
  19544. I've taken some of this out of the Charles Petzold book.  Here's the
  19545. paint case from the window's switch (iMessage) statement.  Note that I
  19546. have declared all the pen and brush types and the RECT structure.
  19547. This code compiles and executes, but doesn't show anything on the
  19548. display other than an "empty" client area.
  19549.  
  19550.  
  19551. case WM_PAINT:
  19552.  
  19553.         /* this gets a handle to the device context, creates the black
  19554.            pen and gray brush, selects them and saves the previous
  19555.            pen and brush to the hOldxxxx handles.  I restore them at
  19556.            the end of the paint routine.  */
  19557.  
  19558.         hDC = BeginPaint (hWnd, &ps);
  19559.         hSolidPen = CreatePen (PS_SOLID, 1, RGB (0, 0, 0) );
  19560.         hGrayBrush = GetStockObject (GRAY_BRUSH);
  19561.         hOldPen = SelectObject (hDC, hSolidPen);
  19562.         hOldBrush = SelectObject (hDC, hGrayBrush);
  19563.  
  19564.  
  19565.         /*  I set the map mode to AnIsotropic, get the coordinates
  19566.             to the client window and store them in the rect struct of
  19567.             type RECT (note GetClientRect returns PHYSICAL coordinates
  19568.             so you can use them directly in the viewport routines without
  19569.             calling the translation routines for physical and logical
  19570.             coordinates).  Using the coordinates of the client window,
  19571.             I set the viewport extent to be the entire client area.
  19572.             Then I shift the viewport origin from the upper left corner
  19573.             of the client window to the lower left corner.  Then I set
  19574.             the x & y axis extents for the logical coordinate system
  19575.             so that I draw using an axis of 0 to 10.  */
  19576.  
  19577.         SetMapMode (hDC, MM_ANISOTROPIC);
  19578.         GetClientRect (hDC, &rect);
  19579.         SetViewportExt (hDC, rect.right, -rect.bottom);
  19580.         SetViewportOrg (hDC, 0, rect.bottom);
  19581.         SetWindowExt (hDC, 10, 10);
  19582.  
  19583.         /* Now draw the rectangle using the logical coordinates */
  19584.         Rectangle (hDC, 1, 1, 8, 8);
  19585.  
  19586.         /* restore the old pen and brush */
  19587.         SelectObject (hDC, hOldPen);
  19588.         SelectObject (hDC, hOldBrush);
  19589.  
  19590.         /* release device context */
  19591.         EndPaint (hDC, &ps);
  19592.         break;
  19593.  
  19594. Thanks in advance for any help.
  19595. David
  19596. ---------------
  19597.  
  19598. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3B2E0951 Date: 07/02/90
  19599. From: GREGORY WILSON                                        Time: 10:15 am
  19600.   To: ALL                                                   (Read 49 times)
  19601. Subj: QC2.5 => MSC6.0??
  19602.  
  19603. I own and use Quick C / Quick ASM 2.5 and recently had a chance to
  19604. try MSC 6.0. I toyed around a bit in the Programmer's Workbench,
  19605. played some with CodeView and then re-compiled some of my QC stuff.
  19606. To my amazment the execution speed of most programs were unchanged
  19607. and one was actually slower! Only 1 out of about 12 showed any
  19608. speed improvment. Code size was about 10% better but is this worth
  19609. the extra bucks??!!
  19610.  
  19611. Being a beginner/intermediate C programmer, maybe I am missing the
  19612. point. What will MSC 6.0/PWB do for me that Quick C does not
  19613. already do. Quick C 2.5 has the ability to set breakpoints, watch
  19614. vars, animate run, quickwatch arrays, ..etc. What else do I need?
  19615. Codeview to me was very awkward and the programmer's workbench was
  19616. SSSSLOW! Quick C is fast and simple to use and is 99.9% compatible
  19617. with MSC6.0.
  19618.  
  19619. Why spend around $350 when Quick C/ASM is only $80?
  19620.  
  19621. Any information will be greatly appreciated.
  19622. Thanks!
  19623. Gregory Wilson
  19624. P.S. The compile options when comparing the compilers were:
  19625. QUICK C > QCL /Ox prog.c
  19626. MSC     > CL /Ox prog.c
  19627. ---------------
  19628. Following thread
  19629.  
  19630. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3B2P1863 Date: 07/02/90
  19631. From: ROBERT BALSOVER                                       Time: 08:31 pm
  19632.   To: GREGORY WILSON (Rcvd)                                 (Read 47 times)
  19633. Subj: R: QC2.5 => MSC6.0??
  19634.  
  19635. Gregory,
  19636.      I have only heard good things about QC/ASM.  I'm not a MS person
  19637. myself, but the others I know that use it agree with you.
  19638. Bob
  19639. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  19640.  
  19641. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3B2K2867 Date: 07/02/90
  19642. From: ANDY HUBBELL                                          Time: 04:47 pm
  19643.   To: ALL                                                   (Read 47 times)
  19644. Subj: INCREMENTING POINTERS
  19645.  
  19646. To all who may have downloaded message number 3AZD0382, I have found a
  19647. solution.  Through some investigating and playing around I found out that
  19648. the function call was the problem.  I took the '*' out of '*dispatch_host'
  19649. and set up the 'value' arrays in the same manner as the 'field' arrays and
  19650. it seems to worl fine.  If you have been looking into my problem as
  19651. detailed in the file ANDY's.ZIP in the conversations area, I appreciate
  19652. the effort.  I thought I would mention the fact that I found a solution so
  19653. that you could stop working on it if you wished.  I will upload a copy of
  19654. my solution in the same area if anyone wants to see it.
  19655.  
  19656. thanks again...andy
  19657. ---------------
  19658.  
  19659. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3B2P0272 Date: 07/02/90
  19660. From: PETER CREAN                                           Time: 08:04 pm
  19661.   To: ALL                                                   (Read 48 times)
  19662. Subj: BTRIEVE FILE MANAGER
  19663.  
  19664. I have recently started programming with the Btrieve File Manager from
  19665. Novell and I cannot get it to create files right from within Turbo Pascal
  19666. 5.5.  It will indexed correctly on the Lstring type when I use the BUTIL
  19667. to create a file but will index on the length on  the Lstring rather than
  19668. the value. Please Help
  19669.                                                    Peter Crean
  19670. ---------------
  19671.  
  19672. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3B3F3254 Date: 07/03/90
  19673. From: SEBASTIAN DEBROGLIE                                   Time: 11:54 am
  19674.   To: GREGORY WILSON (Rcvd)                                 (Read 52 times)
  19675. Subj: HERE'S THE BUGGER
  19676.  
  19677. /*
  19678. Well, strange as it may seem, this code outputs zero for whatever number
  19679. you care to put in.  It's such an impossibly simple program I can't
  19680. believe
  19681. it doesn't work!!!  This is not the actual program--I took this section
  19682. out
  19683. of the scanf.c example in the QC2.0 online tutorial.  It doesn't work
  19684. either!!!
  19685.      If it makes any difference, I'm using CXL libraries version 5.2,
  19686. which I added them to the normal small model library that came with QC2.0.
  19687. Also, I replaced the standard linker with the linker that they said would
  19688. work with OS/2 applications.  In the readme document it said that this
  19689. linker replaced all previous versions.  Even so, was this a mistake??
  19690. I am not making applications for an OS/2 environment--only MS-DOS.
  19691.      THIS IS FRUSTRATING!!!!
  19692.  
  19693.      Thanks a million if you have any ideas on what the problem is.
  19694.  
  19695.      --Sebastian
  19696. */
  19697.  
  19698.  
  19699. #include <stdio.h>
  19700. #include <conio.h>
  19701.  
  19702. main()
  19703. {
  19704.     float fp;
  19705.  
  19706.     /* Get numbers. */
  19707.     printf( "Enter a floating point number: " );
  19708.     scanf( "%f", &fp );
  19709.     printf( "%f\n", fp);
  19710. }
  19711. ---------------
  19712. Following thread
  19713.  
  19714. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3BAF0388 Date: 07/06/90
  19715. From: GREGORY WILSON                                        Time: 11:06 am
  19716.   To: SEBASTIAN DEBROGLIE (Rcvd)                            (Read 44 times)
  19717. Subj: R: HERE'S THE BUGGER
  19718.  
  19719. I tried it with QC2.5, normal libs and it worked fine! Don't know what to
  19720. tell you. You may try adding the <float.h>.
  19721. Let me know what you find out.
  19722. Gregory Wilson
  19723. ---------------
  19724. ** Current thread: HERE'S THE BUGGER
  19725.  
  19726. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3BE10416 Date: 07/10/90
  19727. From: SEBASTIAN DEBROGLIE                                   Time: 01:06 am
  19728.   To: GREGORY WILSON (Rcvd)                                 (Read 24 times)
  19729. Subj: R: HERE'S THE BUGGER
  19730.  
  19731. Well, it was the linker.  I replaced the standard one with another that
  19732. the readme fiel said replaced all previous versions.  It was lying.  There
  19733. was something wrong with it because with the original linker it works
  19734. fine.  I think MS will be getting a letter soon...
  19735.      Thanks for all your time--if you need any help (within the scope of
  19736. my measly programming experience or anyhting else) just ask
  19737.           --Sebastian
  19738. P.S. Sorry for the late response--I've had trouble getting on the system &
  19739. got hung before while leaving you a message.
  19740. ---------------
  19741. ** Current thread: HERE'S THE BUGGER
  19742.  
  19743. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3BEH2664 Date: 07/10/90
  19744. From: GREGORY WILSON                                        Time: 01:44 pm
  19745.   To: SEBASTIAN DEBROGLIE (Rcvd)                            (Read 10 times)
  19746. Subj: R: HERE'S THE BUGGER
  19747.  
  19748. Glad you found the problem!
  19749. Be talkin to you,
  19750. Gregory Wilson
  19751. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  19752.  
  19753. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3BAL1274 Date: 07/06/90
  19754. From: GRANT ELLSWORTH (Leader)                              Time: 05:21 pm
  19755.   To: ALL                                                   (Read 47 times)
  19756. Subj: THE C++ SIDE OF TC++ (OR OTHER)
  19757.  
  19758. Now that TC++ has had time to get loose on several of your hard disks,
  19759. how about sharing your thoughts on using C++.  Does C++ make sense?
  19760. Can or are you using C++ now for anything?  Ready to answer questions
  19761. some of us may have?  Got your fingers burned with it yet?  Grant
  19762. ---------------
  19763. Following thread
  19764.  
  19765. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3BBN3315 Date: 07/07/90
  19766. From: ROBERT BALSOVER                                       Time: 07:55 pm
  19767.   To: GRANT ELLSWORTH (Rcvd)                                (Read 42 times)
  19768. Subj: R: THE C++ SIDE OF TC++ (OR OTHER)
  19769.  
  19770. Grant,
  19771.      There isn't alot of material available that is compatible, I
  19772. downloaded some material from the UNIX area on CIS and it did not compile
  19773. without error.  I wonder if it will truly make programmers more
  19774. productive, or if that is just sales hype.  The stream classes appear to
  19775. output more slowly than the functions in conio.h, perhaps thats just my
  19776. slow 12mz machine.  It would have been nice if Borland made a C++ toolkit
  19777. like the Pascal toolkits, even if just to show more examples of C++ use.
  19778. Bob
  19779. ---------------
  19780. ** Current thread: THE C++ SIDE OF TC++ (OR OTHER)
  19781.  
  19782. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3BC21667 Date: 07/08/90
  19783. From: ROBERT BALSOVER                                       Time: 02:27 am
  19784.   To: GRANT ELLSWORTH (Rcvd)                                (Read 36 times)
  19785. Subj: R: THE C++ SIDE OF TC++ (OR OTHER)
  19786.  
  19787. Grant,
  19788.      I pulled off a file from CIS, a tutorial on overloading operators.
  19789. I uploaded it to the DOS collection.
  19790. Bob
  19791. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  19792.  
  19793. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3BDA2348 Date: 07/09/90
  19794. From: STEVE BOOTH                                           Time: 06:39 am
  19795.   To: ALL                                                   (Read 35 times)
  19796. Subj: WHERE IS CXL?/B
  19797.  
  19798. Message CC'd to:
  19799.      ALL
  19800.      GREGORY WILSON
  19801.  
  19802. Hi All,
  19803.    Does anybody know if Mike Smedley's address is still the same
  19804. as documented in the February 17, 1990 version of CXL?  I tried
  19805. calling the BBS documented and it was disconnected.  I'd like to
  19806. send the guy some money (i.e. register)... If anyone has info
  19807. like the BBS phone number and his address (if it's changed), I'd
  19808. appreciate knowing it.  Thanks!
  19809.  
  19810. Steve...
  19811. ---------------
  19812. Following thread
  19813.  
  19814. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3BDM1376 Date: 07/09/90
  19815. From: GREGORY WILSON                                        Time: 06:22 pm
  19816.   To: STEVE BOOTH (Rcvd)                                    (Read 29 times)
  19817. Subj: R: WHERE IS CXL?/B
  19818.  
  19819. Steve,
  19820. As of last Sunday, Mike Smedley's BBS was shut down. He left the following
  19821. message:
  19822.  
  19823. June 13, 1990
  19824. -------------
  19825. Techworks will be going offline effective Saturday, June 23rd.  At that
  19826. time, I will provide CXL product suport on CompuServe (71331,2244), GEnie
  19827. (M.SMEDLEY), BIX (m.smedley), and the Exec-PC BBS (Mike Smedley).   Many
  19828. personal events have arisen that have kept me from having the time to
  19829. support a BBS system.  I apologize for any inconvenience this may cause.
  19830.  
  19831. You can forget getting any support via EXECPC, CSERVE or GEnie. He has not
  19832. logged onto EXEC since Jan and if you send a msg on CSERVE, you get a note
  19833. back saying that his mailbox is TOOOO full for more msgs.
  19834.  
  19835. It's ashame. It looks like CXL is dead. I would still send the money. It
  19836. will take awhile but the source is very well documented and works like a
  19837. charm. I even recompiled the source under MSC 6.0 with some new
  19838. optimization and it came through perfect!
  19839.  
  19840. I hope he will sell the rights to someone willing to continue development
  19841. on the CXL stuff. I have seen many msgs asking about this but as always no
  19842. response.
  19843.  
  19844. STILL...you get your $35 worth and more!
  19845.  
  19846. Gregory Wilson
  19847. ---------------
  19848. ** Current thread: WHERE IS CXL?/B
  19849.  
  19850. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3BDQ2864 Date: 07/09/90
  19851. From: STEVE BOOTH                                           Time: 09:47 pm
  19852.   To: GREGORY WILSON (Rcvd)                                 (Read 27 times)
  19853. Subj: R: WHERE IS CXL?/B
  19854.  
  19855. Greg, Thanks for the info.  I agree with you wholeheartedly! I'll
  19856.       be sending off a check but won't hold my breath waiting for
  19857.       a response.
  19858.       Best Regards, Steve...
  19859. >>>>>>>>>>>>>>>>>>>>>> Last Message In Thread <<<<<<<<<<<<<<<<<<<<<<
  19860.  
  19861. Conf: PROGRAMMING Topic: C LANGUAGE           Ref: 3BEK2430 Date: 07/10/90
  19862. From: DENNIS DODSON                                         Time: 04:40 pm
  19863.   To: ALL                                                   (Read 8 times)
  19864. Subj: BTRIEVE INTERFACE
  19865.  
  19866. Could someone out there verify for me that before compiling the Btrieve
  19867. 4.0 C interface (mscxbtrv.c) supplied by Novell for linking a Microsoft C
  19868. application with Btrieve, that all you have to change is uncommenting the
  19869. "#define LMODEL 1" if you are using the large memory model and the
  19870. "#define WINDOWS 1" if using windows ?  I am sure that this is true, but
  19871. want to be assured there is nothing else to modify that may cause problems
  19872. with mult-user, file sharing, locks, etc.  Thanks in advance for any help.
  19873.      Dennis
  19874.  
  19875.  
  19876. ---------------
  19877.  
  19878.  
  19879. Exec-PC Conference/topic message menu
  19880. You're in the PROGRAMMING conference, C LANGUAGE topic.
  19881.  
  19882. (209 minutes left) MESSAGE (RNTFSDMLCUXQG, ?=HELP) ->